CVE-2026-53365

What it actually does

This is a Linux kernel denial-of-service flaw in the virtio vsock zerocopy send path. When a large AF_VSOCK message using zerocopy is split across multiple socket buffers, completion accounting is attached only to the final buffer instead of every fragment. Earlier fragments can retain pinned user pages without correct completion tracking, and some error paths can leave pinned pages without a completion notification or clean abort. A local process that can use virtio-vsock zerocopy sends may be able to exhaust pinned memory or related kernel resources, causing memory pressure, degraded performance, failed allocations, process instability, or system-wide denial of service.

Why it matters to the business

Successful exploitation can degrade or disrupt Linux systems that rely on virtio-vsock, particularly virtualized workloads where guest-host communication uses vsock. The most likely consequence is resource exhaustion leading to application failures, host or guest instability, and service interruption. Current public exploitation signals are low: EPSS is 0.00114, the issue is not in CISA KEV, is not known to be used in ransomware, and exploit maturity is listed as none; however, kernel denial-of-service bugs should still be prioritized for systems where untrusted local workloads or multi-tenant virtual machines can access vsock.

How an attack unfolds

An attacker first needs local code execution in a Linux environment where virtio-vsock is available and zerocopy sends can be used. The attacker opens an AF_VSOCK connection, enables or uses zerocopy send behavior, and transmits large messages that are fragmented into multiple socket buffers. Because completion tracking is not correctly associated with every fragment, some pinned user pages are not released or reported correctly. By repeatedly triggering the vulnerable path, the attacker can accumulate pinned memory and pressure kernel memory accounting. Over time this can cause failed allocations, OOM activity, stalled workloads, or broader system instability. There is no indication from the supplied data that remote network-only exploitation is expected; exploitation is most relevant to local users, guest workloads, or processes with access to virtio-vsock.

How to fix it

Apply a Linux kernel update from the operating system, appliance, hypervisor, or distribution vendor that includes the upstream fix for the virtio vsock zerocopy completion handling. Because no exact fixed package versions were provided, use vendor advisories and kernel changelogs to identify builds containing the fix for the vsock/virtio zerocopy multi-skb completion issue. Where immediate patching is not possible, reduce exposure by disabling or restricting virtio-vsock where it is not required, limiting execution of untrusted local workloads, applying cgroup and memory limits to workloads that can access vsock, and monitoring for abnormal pinned memory or OOM activity. Reboot into the patched kernel after installation; merely installing kernel packages is not sufficient if the running kernel remains vulnerable.

How to confirm the fix worked

Confirm the running kernel, not just the installed kernel package, has been updated to a build that includes the vendor fix. Validate with uname -r, distribution package tools, and vendor advisory metadata. Check whether vsock-related modules or devices are present, such as virtio_vsock, vhost_vsock, or /dev/vhost-vsock, to determine exposure. In controlled non-production testing, exercise AF_VSOCK zerocopy large sends and verify that pinned memory does not grow persistently and that zerocopy completions are delivered correctly. Also verify that mitigations such as disabling unused vsock support or restricting workload access remain in place after reboot.

Typical attack path

1. Gain the ability to run code as a local user or workload on a Linux system where virtio-vsock is present.
2. Create or use an AF_VSOCK socket to communicate over the virtio vsock transport.
3. Use zerocopy send behavior, such as MSG_ZEROCOPY or socket zerocopy support, with large messages that fragment into multiple skbs.
4. Repeat multi-fragment sends and trigger normal or error-path behavior that fails to attach completion tracking to all fragments.
5. Accumulate unreleased pinned user pages and consume kernel memory/accounting resources.
6. Cause service degradation, OOM events, process failures, or system instability.

How to detect it

Look for evidence of resource exhaustion correlated with AF_VSOCK or virtio-vsock activity. Relevant sources include kernel logs, systemd journal, audit logs, eBPF or syscall telemetry, endpoint process telemetry, hypervisor or guest logs, and memory-pressure metrics. Search for OOM killer events, allocation failures, hung tasks, sustained reclaim pressure, high locked or pinned memory, and processes repeatedly creating AF_VSOCK sockets or sending large zerocopy messages. On Linux, review dmesg and journalctl for vsock, virtio_vsock, vhost_vsock, OOM, and memory allocation messages. If enhanced telemetry is available, hunt for sendmsg calls using MSG_ZEROCOPY on AF_VSOCK sockets, repeated large sends to VMADDR destinations, and processes whose memory-locked or pinned-page footprint grows without returning to baseline. No public threat actors are identified in the supplied data, so detection should focus on behavioral signs of local resource exhaustion rather than named-campaign indicators.

• virtio_vsock
• vhost_vsock
• AF_VSOCK
• MSG_ZEROCOPY
• SO_ZEROCOPY
• VMADDR_CID
• Out of memory
• oom-killer
• Killed process
• page allocation failure
• Memory allocation failure
• hung task
• blocked for more than
• /dev/vhost-vsock
• /sys/module/virtio_vsock
• /sys/module/vhost_vsock

What your security team should do

• Prioritize patching Linux kernels on virtualization hosts, guest images, CI runners, sandbox systems, and multi-tenant workload platforms where untrusted code can access virtio-vsock.
• Inventory systems with virtio-vsock enabled by checking loaded modules, kernel configuration, virtual device exposure, and use of AF_VSOCK-capable applications.
• If patching must be delayed, disable unused vsock functionality or restrict access to workloads that require it, and apply cgroup memory limits to reduce blast radius.
• Monitor for OOM kills, sustained memory pressure, abnormal pinned memory growth, and processes repeatedly using AF_VSOCK or MSG_ZEROCOPY.
• Treat unexplained host or guest memory exhaustion on systems with vsock enabled as potentially suspicious until logs and workload behavior are reviewed.
• Track vendor kernel advisories because exact fixed versions vary by distribution and product kernel stream.