CVE-2026-52994

What it actually does

This Linux kernel flaw affects virtio vsock handling of MSG_ZEROCOPY sends. Because the kernel accounts pinned user pages after the iterator has already been consumed, the final socket buffer can be charged as zero bytes against RLIMIT_MEMLOCK. A local process capable of using virtio-vsock zerocopy sends may therefore pin memory without proper memlock enforcement, potentially causing excessive pinned memory, memory pressure, degraded performance, or denial of service on affected systems.

Why it matters to the business

Successful exploitation can make Linux virtualized workloads unstable by exhausting or pressuring memory resources, potentially causing service degradation, process termination, guest instability, or host/guest operational disruption depending on deployment. The current public exploitation signal is low: EPSS is 0.00126, there is no known public exploit maturity, it is not listed in CISA KEV, and it is not currently associated with ransomware campaigns; however, kernel resource-exhaustion issues should still be prioritized on multi-tenant, virtualization-heavy, or untrusted-workload platforms.

How an attack unfolds

An attacker first needs local code execution on an affected Linux system where virtio-vsock is available and usable. The attacker opens an AF_VSOCK socket and sends data using MSG_ZEROCOPY in a pattern that causes virtio_transport_fill_skb() to consume the iterator before virtio_transport_init_zcopy_skb() performs pinned-page accounting. On the final socket buffer, the consumed iterator reports a count of zero, so the kernel may skip or undercount RLIMIT_MEMLOCK enforcement for pinned pages. By repeating this behavior, the attacker can pin more memory than normally permitted, creating memory pressure and potentially triggering OOM kills, workload failure, or guest instability. No named threat actor activity or broad exploitation has been reported for this vulnerability based on the provided data.

How to fix it

Apply a vendor-supplied Linux kernel update that includes the fix for virtio vsock MSG_ZEROCOPY pinned-page accounting. The upstream remediation passes the original packet length into virtio_transport_init_zcopy_skb() rather than using the already-consumed iterator count, aligning accounting behavior with TCP and UDP. No exact fixed package versions were provided, so use the relevant distribution, appliance, hypervisor, or cloud image advisory to identify the corrected kernel build. Where immediate patching is not possible, reduce exposure by disabling or restricting virtio-vsock where it is not required, limiting local code execution paths, isolating untrusted workloads, enforcing strict resource controls at the VM/container/orchestrator layer, and monitoring for memory pressure. Mitigations should be validated carefully because disabling vsock can break guest-agent, clipboard, file-sharing, container, or VM management features in some environments.

How to confirm the fix worked

Confirm the running kernel has been updated to a vendor build that includes the vsock/virtio MSG_ZEROCOPY accounting fix. Validate both installed and booted kernel versions, because systems may have patched packages but still be running an older kernel until rebooted. On source-based or custom kernels, verify that virtio_transport_init_zcopy_skb() receives the original packet length for msg_zerocopy_realloc()/mm_account_pinned_pages() accounting rather than relying on iter->count after iterator consumption. Check whether virtio-vsock support is present through kernel configuration and loaded modules such as vsock and virtio_vsock. For exposure validation, identify systems that allow local users, containers, or guests to access AF_VSOCK. In non-production testing, confirm that large MSG_ZEROCOPY vsock sends are constrained by expected memlock/resource limits and do not permit unbounded pinned-memory growth.

Typical attack path

1. Gain local execution on an affected Linux guest or system with virtio-vsock support enabled.
2. Confirm AF_VSOCK and MSG_ZEROCOPY behavior is available to the attacking process.
3. Create a vsock connection to a reachable peer, such as host-to-guest or guest-to-host vsock depending on deployment.
4. Send crafted or repeated zerocopy messages that trigger the vulnerable accounting path on the last socket buffer.
5. Accumulate pinned pages beyond the intended RLIMIT_MEMLOCK limit.
6. Cause memory pressure, degraded service performance, OOM events, or denial of service.

How to detect it

Because this issue is primarily a local kernel resource-accounting flaw, exploitation may not leave a unique network indicator or application log entry. Review kernel logs, system journals, and monitoring data for unexplained memory pressure, OOM killer activity, sudden growth in unevictable or pinned memory, and service instability correlated with processes using vsock. Useful sources include journalctl/kern.log/dmesg, auditd or eBPF syscall telemetry for socket(AF_VSOCK) and sendmsg() with MSG_ZEROCOPY, process accounting, cgroup memory metrics, hypervisor guest-agent logs, and EDR telemetry showing local processes interacting with vsock. Investigate repeated AF_VSOCK traffic from unexpected local users or workloads, especially when followed by OOM events or memlock-limit bypass symptoms. There are no provided threat actors, known exploit kits, or ransomware campaigns tied to this vulnerability, so detection should focus on behavioral anomalies rather than known malicious infrastructure.

• Out of memory: Killed process
• oom-killer
• invoked oom-killer
• Memory cgroup out of memory
• AF_VSOCK
• MSG_ZEROCOPY
• virtio_vsock
• vsock
• RLIMIT_MEMLOCK
• mm_account_pinned_pages

What your security team should do

• Prioritize patching Linux kernels on virtualization hosts, guest images, CI runners, developer workstations, and multi-tenant systems where untrusted local code may run.
• Inventory systems with virtio-vsock enabled or loaded, especially those using guest agents, VM communication channels, or container/VM isolation features.
• Verify that patched kernel packages have actually been booted after maintenance windows.
• Apply compensating controls where patching is delayed: restrict local shell access, isolate untrusted workloads, reduce unnecessary vsock exposure, and enforce VM/container memory limits.
• Monitor kernel and system telemetry for OOM kills, abnormal unevictable or pinned memory growth, and processes making unusual AF_VSOCK zerocopy sends.
• Treat exploitation likelihood as currently low due to no KEV listing, no ransomware association, and low EPSS, but do not defer indefinitely on shared or untrusted-compute platforms.