Re: [PATCH net] packet: use a consistent hard_header_len in send paths

[Willem de Bruijn <willemdebruijn.kernel@gmail.com>]

Qihang wrote:
> Agreed. Caching hard_header_len fixes the RAW paths' inconsistent skb
> arithmetic, but not the SOCK_DGRAM race between headroom allocation and
> header_ops->create().
> 
> I also missed packet_sendmsg_spkt(), which needs the same RAW-path fix.
> 
> Would you prefer a v2 covering the three RAW paths, with the DGRAM
> callback headroom issue handled separately, or both issues in one
> series?

Since the DGRAM path is non-trivial, better to fix that in a separate
patch. Can be same series, but no need to delay the RAW patch for
that. Thanks.
 
> On Wed, Jul 22, 2026 at 10:26 PM Willem de Bruijn
> <willemdebruijn.kernel@gmail.com> wrote:
> >
> > Daniel Zahka wrote:
> > >
> > >
> > > On 7/21/26 4:49 AM, Qihang wrote:
> > > > packet_snd() and tpacket_snd() read dev->hard_header_len multiple times
> > > > while building an skb. Device reconfiguration can change this value
> > > > concurrently, for example through bonding device type changes.
> > > >
> > > > For SOCK_RAW, packet_snd() stores the first value in reserve, later
> > > > allocates headroom using LL_RESERVED_SPACE(dev), and then subtracts
> > > > reserve from the skb headroom. If hard_header_len decreases between the
> > > > reads, the skb can be allocated with less headroom than reserve, moving
> > > > skb->data before skb->head. The subsequent skb_copy_datagram_from_iter()
> > > > can then attempt an out-of-bounds copy. Hardened usercopy catches this as
> > > > a kernel memory overwrite attempt.
> > > >
> > >
> > > Wouldn't there be a similar issue in the SOCK_DGRAM path with
> > > dev_hard_header() calling skb_push() after packet_alloc_skb()?
> >
> > Good point. this does not use hard_header_len directly, but e.g.,
> > eth_header() assumes ETH_HLEN is available to push.
> >
> > Simply caching hard_header_len won't resolve this. dev->hard_header_len
> > and dev->header_ops (incl .create) are not updated atomically.
> >
> > I missed this earlier, but besides packet_snd and tpacket_snd, the fix
> > is also needed by packet_sendmsg_spkt.
> >