CVE-2026-53132

What it actually does

This vulnerability is a denial-of-service flaw in the Linux kernel virtio-vsock receive path. The kernel accounts queued receive data by byte length, but zero-length packets marked with VIRTIO_VSOCK_SEQ_EOM can bypass effective receive-buffer accounting because the queued byte count remains at zero while each packet still consumes socket-buffer metadata memory. A peer that can send crafted virtio-vsock traffic can cause an unbounded number of sk_buff structures to accumulate, exhausting kernel memory or destabilizing the affected system. The issue is resource exhaustion rather than code execution or privilege escalation.

Why it matters to the business

Successful exploitation can make affected Linux systems, virtual machines, or virtualization hosts unstable or unavailable, causing service interruption, VM outages, failed workloads, or host-level operational disruption depending on where virtio-vsock is used. The current public exploitation signal is low: EPSS is 0.00138, it is not listed in CISA KEV, and no mature public exploit is indicated. However, because Linux kernel fixes are often distributed through many downstream operating systems and cloud images, exposure can be widespread in virtualized environments that use vsock-based guest-host communication.

How an attack unfolds

An attacker first needs a position from which they can send traffic over a virtio-vsock communication channel to a vulnerable Linux kernel, such as a malicious or compromised peer in a VM/host communication path. The attacker then establishes or targets a vsock connection and repeatedly sends packets with zero payload length and the end-of-message flag set. Because these packets are not coalesced and have no payload length, the vulnerable receive accounting does not meaningfully increase the tracked receive-byte total, while each packet still allocates kernel socket-buffer metadata. By sustaining the packet stream, the attacker grows the receive queue until kernel memory pressure occurs. The result may be process kills by the OOM killer, degraded performance, socket failures, VM instability, or a kernel crash/panic.

How to fix it

Apply the Linux kernel update that includes the upstream fix for the virtio-vsock receive-queue accounting issue. Because no specific affected package list or fixed downstream versions were provided, obtain the corrected kernel from the relevant Linux distribution, appliance vendor, hypervisor platform, or cloud image provider. Reboot into the patched kernel after installation; simply installing the package is not sufficient if the system continues running the old kernel. Where immediate patching is not possible, reduce exposure by disabling or avoiding virtio-vsock where it is not required, limiting guest-host communication paths, isolating untrusted VMs, and restricting workloads that can access AF_VSOCK endpoints. Mitigations should be treated as temporary because the reliable fix is the corrected kernel accounting behavior.

How to confirm the fix worked

Confirm that systems are running a kernel build that contains the vendor fix for this issue, not only that an updated package is installed. Validate with distribution security advisories, kernel changelogs, package metadata, and the active runtime kernel version. On Linux systems, compare the running kernel from `uname -r` with the fixed kernel provided by the vendor, then verify the system has been rebooted into that kernel. Where kernel source or build metadata is available, confirm the vsock/virtio fix that accounts skb metadata size for queued zero-length packets is present. Also inventory whether virtio-vsock is enabled or in use by checking loaded modules, virtualization configuration, and AF_VSOCK usage by workloads.

Typical attack path

1. Gain the ability to communicate with an affected Linux kernel over virtio-vsock, typically through a guest-host or VM peer communication path.
2. Open or target a vsock endpoint that accepts traffic from the attacker-controlled peer.
3. Send a high volume of zero-length virtio-vsock packets marked with VIRTIO_VSOCK_SEQ_EOM.
4. Cause the vulnerable receive queue to grow by skb metadata count rather than payload byte count.
5. Exhaust kernel memory or trigger severe memory pressure on the receiving system.
6. Disrupt workloads, crash services, trigger OOM kills, or destabilize the VM or host.

How to detect it

There are no known unique public indicators that prove exploitation of this vulnerability. Detection should focus on evidence of abnormal virtio-vsock activity followed by kernel memory exhaustion or system instability. Review kernel logs, system journals, hypervisor logs, VM console logs, and monitoring telemetry for bursts of vsock-related messages, rapid memory pressure, OOM killer events, kernel warnings, soft lockups, or panics. Correlate these events with VM lifecycle activity, guest-host communication, and any unusual workload that can open AF_VSOCK sockets. On hosts, inspect logs around the time of crashes or OOM events for references to `vsock`, `virtio_vsock`, `vhost_vsock`, socket-buffer allocation failures, or call traces involving virtio transport receive functions. Network IDS will usually not see this traffic because virtio-vsock is not conventional IP network traffic; endpoint, kernel, hypervisor, and VM telemetry are the primary sources.

• virtio_vsock
• vhost_vsock
• vsock
• AF_VSOCK
• Out of memory: Killed process
• oom-killer
• page allocation failure
• Kernel panic - not syncing
• BUG: unable to handle kernel
• INFO: task
• blocked for more than
• soft lockup
• virtio_transport_recv_enqueue
• virtio_transport_inc_rx_pkt
• virtio_transport_recv_pkt
• sk_buff
• skb

What your security team should do

• Prioritize patching virtualization hosts, guest images, appliances, and Linux systems that use virtio-vsock or guest-host communication channels.
• Track vendor advisories for the exact fixed kernel versions for each Linux distribution and platform in use, then reboot systems into the patched kernel.
• Inventory exposure by identifying systems with virtio-vsock support enabled, including loaded vsock-related modules and VM configurations that expose vsock communication.
• Restrict or disable virtio-vsock for workloads that do not require it, especially where untrusted or multi-tenant guests can communicate with a host or peer.
• Monitor for sudden kernel memory pressure, OOM killer activity, VM instability, and repeated vsock-related kernel messages as possible signs of attempted exploitation.
• Because this is not currently KEV-listed and has low EPSS, use a risk-based maintenance window, but accelerate remediation for internet-facing virtualization services, shared compute platforms, and environments running untrusted guest workloads.