Re: [Intel-wired-lan] [PATCH] ice: add missing reset of the mac header

[Simon Horman <horms@kernel.org>]

On Fri, Mar 20, 2026 at 07:53:28PM +0000, Loktionov, Aleksandr wrote:
> 
> 
> > -----Original Message-----
> > From: Simon Horman <horms@kernel.org>
> > Sent: Friday, March 20, 2026 7:05 PM
> > To: Loktionov, Aleksandr <aleksandr.loktionov@intel.com>
> > Cc: intel-wired-lan@lists.osuosl.org; Nguyen, Anthony L
> > <anthony.l.nguyen@intel.com>; netdev@vger.kernel.org; Wieczerzycka,
> > Katarzyna <katarzyna.wieczerzycka@intel.com>
> > Subject: Re: [PATCH] ice: add missing reset of the mac header
> > 
> > On Fri, Mar 20, 2026 at 06:05:18AM +0100, Aleksandr Loktionov wrote:
> > > From: Katarzyna Wieczerzycka <katarzyna.wieczerzycka@intel.com>
> > >
> > > By default skb->mac_header is not set, so reset prevents access to
> > an
> > > invalid pointer.
> > >
> > > Call skb_reset_mac_header() before accessing the mac header from
> > skb.
> > >
> > > Signed-off-by: Katarzyna Wieczerzycka
> > > <katarzyna.wieczerzycka@intel.com>
> > > Signed-off-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
> > 
> > Hi Katarzyna and Aleksandr,
> > 
> > I am curious:
> > 
> > Is this a bug? If so then it should probably have a fixes tag and a
> > bit more of a description around how this can happen.
> > 
> > If it is not a bug, then is this defensive? And if so, is it really
> > necessary?
> > 
> > ...
> 
> 
> Good day, Simon
> 
> I'm upstreaming Katarzyna's fix.
> 
> From my point of view, it's not just defensive code, but real bug even on latest kernel because the gap is partially closed by packet_parse_headers(), but not completely.
> Sorry the patch header is malformed, I definitely need to add 
> Fixes: f9f83202b726 ("ice: Allow all LLDP packets from PF to Tx")

Hi Aleksandr,

I can see you have been busy.

I agree adding a Fixes tag makes sense.  If you could also expand the patch
description that would be well appreciated (at least by me).

> But not sure whether to send to net, because on modern kernels I have no real call traces only theoretical conclusion.

That is a line call in my opinion.

If you include a Fixes tag, which seems sensible, then the chances are the
patch will end up being backported to stable. And if the patch is in
net-next it might not have hit Linus's tree before that happens. Which
doesn't seem ideal. So I think it would be more sensible to target the
patch at net to avoid that problem. But that's just my feeling.

Either way, please consider adding a note regarding this.
So it will be more obvious.