Netdev List
 help / color / mirror / Atom feed
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)

             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