In the Linux kernel, the following vulnerability has been resolved: net/packet: prevent TX_RING byte count overflow 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.
Fix
Nothing published yet: no patch, vendor advisory or mitigation reference on NVD, no vendor advisory in the News for this CVE, not in CISA's KEV, no fixed package version. BaselineWatch does not guess at one.
Change history 5
- StatusReceived → PublishedNVD modified 2026-10-21 12:57
- References+1 references (now 5)NVD modified 2026-10-21 13:21
- StatusPublished → ReceivedNVD modified 2026-10-21 13:21
- StatusReceived → PublishedNVD modified 2026-10-19 09:26
- First seenunscoredNVD modified 2026-10-19 10:19
Affected (CPE criteria) 0
NVD has not attached CPE configurations yet.
References 5
- https://git.kernel.org/stable/c/2cf81fc9505b148b1b70068303ea6ea4b1212403
- https://git.kernel.org/stable/c/69ca64bbb528898916f309552053c32a04a36ebc
- https://git.kernel.org/stable/c/9fd63d284e251332f4874ef9023cde472f315f86
- https://git.kernel.org/stable/c/ae169d318d5d23bac76ece90a7e2b5cb760ed043
- https://git.kernel.org/stable/c/be12b221c0301111eeb023be04add3c6ad7c21fe