From: "Ilkka Lappeteläinen" <ilkka.lappetelainen@gmail.com>
To: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
Cc: netdev@vger.kernel.org, security@kernel.org
Subject: [PATCH net] net/packet: prevent TX_RING byte count overflow
Date: Fri, 25 Sep 2026 15:48:29 +0300 [thread overview]
Message-ID: <20260925124829.6595-1-ilkka.lappetelainen@gmail.com> (raw)
tpacket_snd() drains every SEND_REQUEST frame in a TX ring and adds
each valid packet length to the signed int len_sum. Userspace can
recycle completed frames concurrently, so a single blocking send call
is not bounded by the ring size.
After enough successful transmissions len_sum wraps into the negative
range. In particular, 65536 65535-byte frames followed by a 65007-byte
frame produce 0xfffffdef, or -EIOCBQUEUED. sock_sendmsg_nosec() treats
that as an impossible return and triggers a BUG. On systems configured
to panic on oops, a CAP_NET_RAW holder can panic the host kernel.
Stop before the next frame would make the byte count exceed INT_MAX.
The positive short count leaves that frame pending for a later send
call.
A two-thread TPACKET_V2 reproducer triggered the BUG on an arm64 build
of Linux 7.3-rc4. With this change, the same reproducer returned the
expected positive short count without an oops.
Fixes: 69e3c75f4d54 ("net: TX_RING and packet mmap")
Cc: stable@vger.kernel.org
Assisted-by: LLM
Signed-off-by: Ilkka Lappeteläinen <ilkka.lappetelainen@gmail.com>
---
A tested C reproducer is available privately on request. The exact kernel
configuration and complete vulnerable and patched console logs are also
available on request.
The test uses CAP_NET_ADMIN only to configure a high-MTU dummy interface
for fast reproduction. The vulnerable send path itself requires
CAP_NET_RAW; an existing active interface can be used, with smaller MTUs
requiring more frames.
net/packet/af_packet.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c
index 7c83e01526ed..d2c98bc0de9c 100644
--- a/net/packet/af_packet.c
+++ b/net/packet/af_packet.c
@@ -2874,6 +2874,9 @@ static int tpacket_snd(struct packet_sock *po, struct msghdr *msg)
vnet_hdr.hdr_len);
has_vnet_hdr = true;
}
+ /* Prevent the byte count from wrapping into a negative errno. */
+ if (unlikely(tp_len > INT_MAX - len_sum))
+ break;
copylen = max_t(int, copylen, hard_header_len);
skb = sock_alloc_send_skb(&po->sk,
hlen + tlen + sizeof(struct sockaddr_ll) +
base-commit: 165768bb70265b5c38cf0b73fafd75be235f8b14
--
2.50.1 (Apple Git-155)
next reply other threads:[~2026-09-25 12:48 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-25 12:48 Ilkka Lappeteläinen [this message]
2026-09-27 20:37 ` [PATCH net] net/packet: prevent TX_RING byte count overflow Willem de Bruijn
2026-09-29 23:50 ` patchwork-bot+netdevbpf
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=20260925124829.6595-1-ilkka.lappetelainen@gmail.com \
--to=ilkka.lappetelainen@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=security@kernel.org \
--cc=willemdebruijn.kernel@gmail.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox