CVE-2026-98850: net/packet: prevent TX_RING byte count overflow
In the Linux kernel, the following vulnerability has been resolved:
net/packet: prevent TXRING byte count overflow
tpacketsnd() drains every SENDREQUEST frame in a TX ring and adds each valid packet length to the signed int lensum. Userspace can recycle completed frames concurrently, so a single blocking send call is not bounded by the ring size.
After enough successful transmissions lensum wraps into the negative range. In particular, 65536 65535-byte frames followed by a 65007-byte frame produce 0xfffffdef, or -EIOCBQUEUED. socksendmsgnosec() treats that as an impossible return and triggers a BUG. On systems configured to panic on oops, a CAPNETRAW holder can panic the host kernel.
Stop before the next frame would make the byte count exceed INTMAX. The positive short count leaves that frame pending for a later send call.
A two-thread TPACKETV2 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.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
Linux kernelto a version that resolves this vulnerability.Fixed in 7.3-rc4
Event History
Frequently Asked Questions
Who can exploit this issue in practice?
An attacker needs CAP_NET_RAW and the ability to use a packet socket TX ring. The described impact is a kernel BUG and, on systems configured to panic on oops, a host kernel panic.
What conditions are required to trigger the overflow?
The trigger requires a blocking send call draining TX_RING frames while userspace concurrently recycles completed frames, allowing the accumulated transmitted-byte count to grow beyond a signed integer limit. The provided reproducer used two threads and TPACKET_V2.
How can I tell whether the system has been affected?
The described failure causes sock_sendmsg_nosec() to encounter the wrapped negative value and trigger a BUG. On systems that panic on oops, this may appear as a kernel panic during packet-socket TX_RING activity.
What behavior changes after the fix?
The kernel stops processing before adding a frame that would make the byte count exceed INT_MAX. It returns a positive short count and leaves that frame pending for a later send call, rather than reaching the BUG condition.