Linux Kernel CVE-2026-52994

The attacker must have local, low-privilege access to a Linux system (CVSS PR:L, AV:L). The virtio-vsock kernel module must be loaded and AF_VSOCK socket creation must be permitted for the attacker's user or process context - this is not a default condition on general-purpose Linux but is common in virtualized environments (KVM guests, QEMU, cloud VMs). The attacker must be able to send data over vsock using the MSG_ZEROCOPY flag, which requires a listening peer on the other end of the socket. The kernel version must fall in the range from commit 581512a6dc939ef122e49336626ae159f3b8a345 (around 6.7) to the fixed releases. Systems that do not load virtio-vsock, restrict vsock to root-only, or run fixed kernel versions are not affected. Remote exploitation is impossible - this is a local resource-accounting bypass only.

The CVSS 3.1 vector AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H is internally consistent with the description: exploitation is strictly local, requires only unprivileged credentials, involves no scope change, and produces an availability impact through uncapped memory pinning. The EPSS probability of 0.17% (7th percentile) and absence from CISA KEV both indicate this is not being actively exploited or targeted. The practical blast radius is further constrained by the requirement that the virtio-vsock module be loaded and that the attacker have the ability to create AF_VSOCK sockets - a condition not met in most general-purpose Linux deployments, making exploitation realistic primarily in hypervisor-guest or container-with-vsock environments. The 'Information Disclosure' tag applied in the source intelligence is inconsistent with the CVSS C:N metric and the CVE description, which describes no data leakage mechanism; this tag should be disregarded. Net assessment: low real-world priority for most environments, but relevant for cloud or VDI infrastructure operators where vsock is actively used. The fix is available, so patching on the normal kernel update cadence is the correct response.

A local user on a virtualized Linux host (e.g., a guest VM or a container with AF_VSOCK access) opens a vsock socket to a listening peer and repeatedly sends large payloads with the MSG_ZEROCOPY flag. Each send causes the kernel to pin the user's pages but only partially accounts for them against RLIMIT_MEMLOCK - specifically, the last skb of each send records zero bytes. By looping this operation, the attacker progressively pins memory far beyond their RLIMIT_MEMLOCK budget, driving the host kernel toward memory pressure or OOM conditions and denying service to other tenants. No public exploit code has been identified at the time of analysis.