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

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

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.