From: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
To: Qihang <q.h.hack.winter@gmail.com>, netdev@vger.kernel.org
Cc: willemdebruijn.kernel@gmail.com, daniel.zahka@gmail.com,
davem@davemloft.net, edumazet@google.com, kuba@kernel.org,
pabeni@redhat.com, horms@kernel.org, stable@vger.kernel.org,
Qihang <q.h.hack.winter@gmail.com>
Subject: Re: [PATCH net v2] packet: use consistent header lengths in raw send paths
Date: Sun, 26 Jul 2026 11:21:33 -0400 [thread overview]
Message-ID: <willemdebruijn.kernel.328be8a5ee86b@gmail.com> (raw)
In-Reply-To: <20260726092110.80185-1-q.h.hack.winter@gmail.com>
Qihang wrote:
> packet_snd(), tpacket_snd(), and packet_sendmsg_spkt() read
> dev->hard_header_len multiple times while allocating and constructing an
> skb. Device reconfiguration can change this value concurrently, for
> example through bonding device type changes.
>
> For SOCK_RAW, packet_snd() can save a larger value in reserve and later
> allocate headroom using a smaller value. Moving skb->data back by reserve
> then places it before skb->head, and the following copy from userspace can
> attempt an out-of-bounds write.
>
> tpacket_snd() similarly uses independent values for allocation and for
> the skb_push()/skb_put() operations in tpacket_fill_skb(). The legacy
> packet_sendmsg_spkt() path also calculates its reservation and header
> offset from separate reads before dropping the RCU read lock to allocate
> the skb. A larger offset than reservation can move skb->data before
> skb->head, while mixed TX-ring values can also make
> copylen - hard_header_len negative.
>
> Read hard_header_len once for each send operation and use that value for
> RAW allocation and construction. The trigger requires racing an
> AF_PACKET sender with privileged netdevice reconfiguration.
>
> The separate SOCK_DGRAM consistency problem between hard_header_len and
> header_ops->create is not addressed here.
>
> Fixes: b84bbaf7a6c8 ("packet: in packet_snd start writing at link layer allocation")
> Fixes: 69e3c75f4d54 ("net: TX_RING and packet mmap")
Not sure whether a patch can have two fixes tags.
Maybe better two separate patches.
> Cc: stable@vger.kernel.org
> Signed-off-by: Qihang <q.h.hack.winter@gmail.com>
> ---
> v2:
> - Cover packet_sendmsg_spkt().
> - Limit snapshot-based calculations to RAW construction; leave DGRAM
> unchanged for a separate fix.
>
> Link to v1: https://lore.kernel.org/netdev/20260721084935.12312-1-q.h.hack.winter@gmail.com/
> ---
> net/packet/af_packet.c | 64 ++++++++++++++++++++++++++++++------------
> 1 file changed, 46 insertions(+), 18 deletions(-)
>
> diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c
> index e75d2932475a..d23898f24641 100644
> --- a/net/packet/af_packet.c
> +++ b/net/packet/af_packet.c
> @@ -1953,6 +1953,7 @@ static int packet_sendmsg_spkt(struct socket *sock, struct msghdr *msg,
> struct net_device *dev;
> struct sockcm_cookie sockc;
> __be16 proto = 0;
> + unsigned int hard_header_len = 0;
Please keep reverse xmas tree ordering when not too inconvenient.
> int err;
> int extra_len = 0;
>
> @@ -1996,15 +1997,21 @@ static int packet_sendmsg_spkt(struct socket *sock, struct msghdr *msg,
> }
> extra_len = 4; /* We're doing our own CRC */
> }
> + if (!skb)
Why this branch?
> + hard_header_len = READ_ONCE(dev->hard_header_len);
>
> err = -EMSGSIZE;
> - if (len > dev->mtu + dev->hard_header_len + VLAN_HLEN + extra_len)
> + if (len > dev->mtu + hard_header_len + VLAN_HLEN + extra_len)
> goto out_unlock;
>
> if (!skb) {
> - size_t reserved = LL_RESERVED_SPACE(dev);
> + size_t reserved;
> int tlen = dev->needed_tailroom;
> - unsigned int hhlen = dev->header_ops ? dev->hard_header_len : 0;
> + unsigned int hhlen = READ_ONCE(dev->header_ops) ?
Why add this READ_ONCE? Other header_ops readers lack this.
> + hard_header_len : 0;
> +
> + reserved = ((hard_header_len + READ_ONCE(dev->needed_headroom)) &
> + ~(HH_DATA_MOD - 1)) + HH_DATA_MOD;
Now that this file uses this three times, it might be worthwhile
creating an LL_RESERVED_SPACE_EX(dev, hhlen) wrapper. And have
LL_RESERVED_SPACE call that. (optional).
>
> rcu_read_unlock();
> skb = sock_wmalloc(sk, len + reserved + tlen, 0, GFP_KERNEL);
> @@ -2569,6 +2576,7 @@ static int packet_snd_vnet_parse(struct msghdr *msg, size_t *len,
> static int tpacket_fill_skb(struct packet_sock *po, struct sk_buff *skb,
> void *frame, struct net_device *dev, void *data, int tp_len,
> __be16 proto, unsigned char *addr, int hlen, int copylen,
> + int hard_header_len,
Inconsistent unsigned int above vs int here. Dev field is unsigned
short. Int is fine.
> const struct sockcm_cookie *sockc)
> {
> union tpacket_uhdr ph;
> @@ -2600,8 +2608,8 @@ static int tpacket_fill_skb(struct packet_sock *po, struct sk_buff *skb,
> } else if (copylen) {
> int hdrlen = min_t(int, copylen, tp_len);
>
> - skb_push(skb, dev->hard_header_len);
> - skb_put(skb, copylen - dev->hard_header_len);
> + skb_push(skb, hard_header_len);
> + skb_put(skb, copylen - hard_header_len);
> err = skb_store_bits(skb, 0, data, hdrlen);
> if (unlikely(err))
> return err;
> @@ -2732,7 +2740,7 @@ static int tpacket_snd(struct packet_sock *po, struct msghdr *msg)
> void *data;
> int len_sum = 0;
> int status = TP_STATUS_AVAILABLE;
> - int hlen, tlen, copylen = 0;
> + int hard_header_len = 0, hlen, tlen, copylen = 0;
> long timeo;
>
> mutex_lock(&po->pg_vec_lock);
> @@ -2779,8 +2787,10 @@ static int tpacket_snd(struct packet_sock *po, struct msghdr *msg)
> goto out_put;
> }
>
> - if (po->sk.sk_socket->type == SOCK_RAW)
> - reserve = dev->hard_header_len;
> + if (po->sk.sk_socket->type == SOCK_RAW) {
> + hard_header_len = READ_ONCE(dev->hard_header_len);
> + reserve = hard_header_len;
> + }
> size_max = po->tx_ring.frame_size
> - (po->tp_hdrlen - sizeof(struct sockaddr_ll));
>
> @@ -2817,7 +2827,12 @@ static int tpacket_snd(struct packet_sock *po, struct msghdr *msg)
> goto tpacket_error;
>
> status = TP_STATUS_SEND_REQUEST;
> - hlen = LL_RESERVED_SPACE(dev);
> + if (po->sk.sk_socket->type == SOCK_RAW)
> + hlen = ((hard_header_len +
Here and elsewhere: why special case this only for SOCK_RAW?
This complicates control flow.
> + READ_ONCE(dev->needed_headroom)) &
> + ~(HH_DATA_MOD - 1)) + HH_DATA_MOD;
> + else
> + hlen = LL_RESERVED_SPACE(dev);
> tlen = dev->needed_tailroom;
> if (vnet_hdr_sz) {
> data += vnet_hdr_sz;
> @@ -2835,10 +2850,14 @@ static int tpacket_snd(struct packet_sock *po, struct msghdr *msg)
> vnet_hdr.hdr_len);
> has_vnet_hdr = true;
> }
> - copylen = max_t(int, copylen, dev->hard_header_len);
> + if (po->sk.sk_socket->type == SOCK_RAW)
> + copylen = max_t(int, copylen, hard_header_len);
> + else
> + copylen = max_t(int, copylen, dev->hard_header_len);
> skb = sock_alloc_send_skb(&po->sk,
> hlen + tlen + sizeof(struct sockaddr_ll) +
> - (copylen - dev->hard_header_len),
> + (copylen - (po->sk.sk_socket->type == SOCK_RAW ?
> + hard_header_len : dev->hard_header_len)),
> !need_wait, &err);
>
> if (unlikely(skb == NULL)) {
> @@ -2848,7 +2867,8 @@ static int tpacket_snd(struct packet_sock *po, struct msghdr *msg)
> goto out_status;
> }
> tp_len = tpacket_fill_skb(po, skb, ph, dev, data, tp_len, proto,
> - addr, hlen, copylen, &sockc);
> + addr, hlen, copylen, hard_header_len,
> + &sockc);
> if (likely(tp_len >= 0) &&
> tp_len > dev->mtu + reserve &&
> !vnet_hdr_sz &&
> @@ -2956,7 +2976,7 @@ static int packet_snd(struct socket *sock, struct msghdr *msg, size_t len)
> int offset = 0;
> struct packet_sock *po = pkt_sk(sk);
> int vnet_hdr_sz = READ_ONCE(po->vnet_hdr_sz);
> - int hlen, tlen, linear;
> + int hard_header_len = 0, hlen, tlen, linear;
> int extra_len = 0;
>
> /*
> @@ -2996,14 +3016,17 @@ static int packet_snd(struct socket *sock, struct msghdr *msg, size_t len)
> goto out_unlock;
> }
>
> - if (sock->type == SOCK_RAW)
> - reserve = dev->hard_header_len;
> if (vnet_hdr_sz) {
> err = packet_snd_vnet_parse(msg, &len, &vnet_hdr, vnet_hdr_sz);
> if (err)
> goto out_unlock;
> }
>
> + if (sock->type == SOCK_RAW) {
> + hard_header_len = READ_ONCE(dev->hard_header_len);
> + reserve = hard_header_len;
> + }
> +
> if (unlikely(sock_flag(sk, SOCK_NOFCS))) {
> if (!netif_supports_nofcs(dev)) {
> err = -EPROTONOSUPPORT;
> @@ -3018,10 +3041,15 @@ static int packet_snd(struct socket *sock, struct msghdr *msg, size_t len)
> goto out_unlock;
>
> err = -ENOBUFS;
> - hlen = LL_RESERVED_SPACE(dev);
> + if (sock->type == SOCK_RAW)
> + hlen = ((hard_header_len + READ_ONCE(dev->needed_headroom)) &
> + ~(HH_DATA_MOD - 1)) + HH_DATA_MOD;
> + else
> + hlen = LL_RESERVED_SPACE(dev);
> tlen = dev->needed_tailroom;
> linear = __virtio16_to_cpu(vio_le(), vnet_hdr.hdr_len);
> - linear = max(linear, min_t(int, len, dev->hard_header_len));
> + linear = max(linear, min_t(int, len, sock->type == SOCK_RAW ?
> + hard_header_len : dev->hard_header_len));
> skb = packet_alloc_skb(sk, hlen + tlen, hlen, len, linear,
> msg->msg_flags & MSG_DONTWAIT, &err);
> if (skb == NULL)
> @@ -3037,7 +3065,7 @@ static int packet_snd(struct socket *sock, struct msghdr *msg, size_t len)
> } else if (reserve) {
> skb_reserve(skb, -reserve);
> if (len < reserve + sizeof(struct ipv6hdr) &&
> - dev->min_header_len != dev->hard_header_len)
> + dev->min_header_len != hard_header_len)
> skb_reset_network_header(skb);
> }
>
> --
> 2.50.1 (Apple Git-155)
>
prev parent reply other threads:[~2026-07-26 15:21 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-21 8:49 [PATCH net] packet: use a consistent hard_header_len in send paths Qihang
2026-07-21 16:01 ` Daniel Zahka
2026-07-22 14:26 ` Willem de Bruijn
2026-07-24 3:36 ` Qihang
2026-07-25 7:39 ` Willem de Bruijn
2026-07-26 9:21 ` [PATCH net v2] packet: use consistent header lengths in raw " Qihang
2026-07-26 15:21 ` Willem de Bruijn [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=willemdebruijn.kernel.328be8a5ee86b@gmail.com \
--to=willemdebruijn.kernel@gmail.com \
--cc=daniel.zahka@gmail.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=horms@kernel.org \
--cc=kuba@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=q.h.hack.winter@gmail.com \
--cc=stable@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.