CVE-2026-98850 in Linux
Summary
by MITRE • 10/18/2026
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.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/18/2026
The vulnerability identified in the Linux kernel network subsystem involves a critical integer overflow within the packet socket implementation, specifically affecting the TX_RING functionality used for high-performance packet transmission. The core of the issue resides in the tpacket_snd function, which is responsible for processing frames queued for transmission on a transmit ring buffer. This function iterates through every SEND_REQUEST frame present in the ring and accumulates their valid packet lengths into a signed integer variable named len_sum. Under normal operational conditions with single-threaded access or strictly bounded send calls, this accumulation would remain within safe limits relative to the ring size. However, the architecture of TPACKET_V2 allows userspace applications to recycle completed frames concurrently while new data is being submitted. This concurrency model means that a single blocking send call is not inherently bounded by the static size of the transmit ring because other threads or processes may be simultaneously completing and freeing up space in the ring, allowing more packets to be queued than initially anticipated within the context of one specific system call invocation.
The technical flaw arises from the lack of overflow protection on the len_sum variable during this accumulation process. Since len_sum is a signed 32-bit integer, it has a maximum positive value defined by INT_MAX. When enough successful transmissions occur such that the total byte count exceeds this limit, the variable wraps around into the negative range due to standard two's complement arithmetic behavior. For instance, sending sixty-five thousand five hundred and thirty-six frames of sixty-five thousand five hundred and thirty-five bytes each, followed by a single frame of sixty-five thousand seven bytes, results in an accumulated value that overflows to 0xfffffdef, which corresponds to the negative error code -EIOCBQUEUED. This specific numeric collision is particularly dangerous because it mimics a valid kernel internal error state rather than being recognized as a simple arithmetic overflow or resource exhaustion condition.
The operational impact of this vulnerability is severe, leading directly to a denial-of-service scenario through kernel panic. When sock_sendmsg_nosec receives the negative value -EIOCBQUEUED from tpacket_snd, it interprets this return code as an impossible or unexpected error state rather than a valid indication that the ring was full or processing limits were reached. Consequently, the kernel triggers a BUG_ON condition, which generates an oops trace and, on systems configured with panic_on_oops enabled, results in a complete host kernel panic. This means that any unprivileged user possessing the CAP_NET_RAW capability can exploit this race condition to crash the entire system by carefully crafting packet sizes and leveraging concurrent frame recycling to trigger the integer overflow. The vulnerability was confirmed using a two-thread reproducer on an ARM64 build of Linux version 7.3-rc4, where it successfully triggered the BUG state before mitigation.
The remediation strategy implemented in the kernel involves modifying tpacket_snd to enforce strict bounds checking during the accumulation phase. Specifically, the code now checks whether adding the next frame's length would cause len_sum to exceed INT_MAX. If such an overflow is imminent, the function stops processing further frames for that call and returns a positive short count instead of allowing the addition to proceed. This approach ensures that the byte count remains within valid signed integer limits while still providing feedback to userspace about how many bytes were successfully queued. The frame that would have caused the overflow is left pending in the ring buffer, making it available for subsequent send calls where space may be freed by completed transmissions from other threads. With this patch applied, the same reproducer that previously crashed the kernel now returns the expected positive short count without triggering an oops or panic, effectively neutralizing the denial-of-service vector while maintaining functional integrity of the packet socket interface.
From a classification perspective, this vulnerability aligns with CWE-190 Integer Overflow or Wraparound, as the root cause is the failure to handle arithmetic operations that exceed the capacity of the data type used for storage. It also relates closely to CWE-362 Concurrent Execution using Shared Resource with Improper Synchronization, given that the exploit relies on concurrent userspace actions interacting with kernel-side state in a way that bypasses expected bounds checks designed for single-threaded scenarios. In terms of adversarial tactics, this vulnerability can be mapped to MITRE ATT&CK technique T1529 System Shutdown or Reboot, as an attacker utilizes it specifically to cause a system crash and deny service to legitimate users. The mitigation emphasizes the importance of rigorous input validation and bounds checking in kernel-space network handlers that process variable-length data from untrusted userspace contexts, ensuring that arithmetic accumulations are protected against overflow even under high-concurrency conditions typical of modern packet processing applications like DPDK or custom networking stacks.