[PATCH net] net/packet: prevent TX_RING byte count overflow

[PATCH net] net/packet: prevent TX_RING byte count overflow

[Ilkka Lappeteläinen]

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)

Re: [PATCH net] net/packet: prevent TX_RING byte count overflow

[Willem de Bruijn]

Ilkka Lappeteläinen wrote:
> 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>

Reviewed-by: Willem de Bruijn <willemb@google.com>

Re: [PATCH net] net/packet: prevent TX_RING byte count overflow

[patchwork-bot+netdevbpf]

Hello:

This patch was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:

On Fri, 25 Sep 2026 15:48:29 +0300 you wrote:
> 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.
> 
> [...]

Here is the summary with links:
  - [net] net/packet: prevent TX_RING byte count overflow
    https://git.kernel.org/netdev/net/c/2cf81fc9505b

You are awesome, thank you!
-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html