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

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
[off-list ref] wrote:

quoted

Daniel Zahka wrote:

quoted

On 7/21/26 4:49 AM, Qihang wrote:

quoted

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.