Cloudanix VulnDB

CVE-2026-98850

None

CVSS

—

EPSS

0.2%

Published

Oct 18, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A local user with special network privileges can send crafted packets that cause the operating system kernel to crash the whole machine.

Exploitation
Local Privilege
Attacker needs
Low Privilege
Complexity
Moderate
Impact
Denial Of Service
Component
OS kernel
Class
Race Condition
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

A race condition in tpacket_snd() allows concurrent userspace frame recycling to cause signed integer overflow of len_sum when transmitting many large packets via AF_PACKET TX_RING, leading to a negative return value that triggers a BUG() in sock_sendmsg_nosec().

Why it matters to the business

A local user with packet capture privileges can crash the entire system on kernels configured to panic on oops, causing denial of service and potential data loss or service interruption on affected hosts.

How an attack unfolds

An attacker with CAP_NET_RAW creates a TPACKET_V2 TX ring, submits many maximum-sized frames, and uses a second thread to recycle completed frames so that the cumulative byte count exceeds INT_MAX; the resulting negative value from tpacket_snd() is treated as an error by sock_sendmsg_nosec() and panics the kernel.

How to fix it

Upgrade the Linux kernel to a version containing the fix that checks the byte count against INT_MAX before adding the next frame; apply the patch or install the vendor-supplied kernel update as soon as it is available.

How to confirm the fix worked

Confirm the running kernel version includes the upstream commit that adds the INT_MAX check in tpacket_snd(); attempt to reproduce the two-thread TPACKET_V2 test case and verify it now returns a short positive count instead of triggering BUG().

Typical attack path

  1. Obtain CAP_NET_RAW capability on the target host
  2. Create an AF_PACKET socket with TPACKET_V2 TX_RING
  3. Fill the ring with many 65535-byte frames and begin transmission
  4. Concurrently recycle completed frames from userspace to evade ring-size bounds
  5. Trigger the final frame that causes len_sum to wrap negative
  6. Cause BUG() and kernel panic on systems with panic-on-oops enabled

How to detect it

Look for kernel oops or panic logs containing references to sock_sendmsg_nosec, tpacket_snd, or net/packet; correlate with processes holding CAP_NET_RAW and using AF_PACKET sockets.

What your security team should do

  • Prioritize kernel updates on systems where panic-on-oops is enabled
  • Restrict CAP_NET_RAW to the minimum set of trusted processes and users
  • Monitor for kernel oops or panic events involving net/packet or tpacket_snd
  • Apply the fix within normal patch windows given the low EPSS and absence from KEV

The record

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.

Affected packages

Ecosystem Package Introduced Fixed