Cloudanix VulnDB

CVE-2026-99062

None

CVSS

—

EPSS

0.2%

Published

Oct 23, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A recently fixed Linux kernel bug could make certain virtual-machine communication sockets report wrong amounts of data or refuse to deliver messages they actually hold, leading to application errors until systems are updated.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
Moderate
Impact
Other
Component
OS kernel
Class
Memory Corruption
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

Integer underflow in vsock/virtio receive accounting allows rx_bytes to become negative or wrap after partial reads on connected streams when SKB verdicts are used, causing incorrect SIOCINQ values, spurious ELOOP on recv, and poll reporting empty sockets as readable while hiding queued data.

Why it matters to the business

Systems relying on virtio-vsock for guest-host or inter-VM communication may experience unexpected socket errors, stalled data transfer, or misleading readiness notifications, increasing operational troubleshooting effort and risk of application-level failures on recently patched kernels.

How an attack unfolds

An attacker establishes a CID_LOCAL vsock stream, sends a multi-byte packet, performs a partial read, and triggers an SK_SKB verdict; the kernel then dequeues the packet while passing full length for all counters, underflowing rx_bytes and producing the observable misbehavior on subsequent operations.

How to fix it

Update to a kernel containing the fix that subtracts only (skb->len minus VSOCK offset) from rx_bytes while retaining full packet length for buf_used and peer credit; rebuild and reboot affected hosts.

How to confirm the fix worked

After patching, repeat the 40-byte read from a 100-byte packet scenario and confirm SIOCINQ reports the correct remaining length, recv succeeds without ELOOP, and poll accurately reflects queued data.

Typical attack path

  1. Connect to a local vsock endpoint
  2. Send a packet larger than the first read size
  3. Apply an SK_SKB verdict that detaches after partial consumption
  4. Observe negative or wrapped rx_bytes via ioctl or recv returning ELOOP
  5. Continue reading to trigger further accounting wrap and data hiding

How to detect it

Search kernel and application logs for ELOOP errors on vsock file descriptors, negative values returned by SIOCINQ ioctls, or poll events indicating readability on sockets that subsequently return zero bytes; correlate with virtio_transport_read_skb call sites.

What your security team should do

  • Prioritize kernel updates on hosts using virtio-vsock within the next maintenance window given the two-day publication age
  • Audit vsock-dependent services for partial-read patterns that could trigger the accounting error
  • Add monitoring for ELOOP returns and negative SIOCINQ values in vsock-using workloads

The record

In the Linux kernel, the following vulnerability has been resolved: vsock/virtio: account only unread bytes in read_skb() After a partial stream receive, rx_bytes tracks the unread suffix while buf_used and peer credit still cover the whole packet. virtio_transport_read_skb() dequeues that packet but passes pkt_len for both counters, underflowing rx_bytes. On a connected CID_LOCAL stream with an SK_SKB verdict, a 40-byte read from a 100-byte packet made SIOCINQ report -40, an empty recv return ELOOP, and poll report the empty socket readable. After verdict detach, receiving 40 bytes wrapped the counter to zero and hid those queued bytes until one more byte arrived. The fixed run kept the counter balanced and exposed all queued data immediately. This was found during an LLM-assisted manual source audit of VSOCK receive accounting while re-evaluating virtio_transport_read_skb() after CVE-2024-50169. Subtract only skb->len minus the VSOCK offset from rx_bytes. Retain the full packet length for buf_used and peer credit.

Affected packages

Ecosystem Package Introduced Fixed