CVE-2026-64115: Linux Kernel Use-After-Free Vulnerability

CVE-2026-64115 Overview

CVE-2026-64115 is a use-after-free (UAF) vulnerability in the Linux kernel's vsock/vmci transport layer. The flaw exists in vmci_transport_recv_connecting_server(), which incorrectly returned err = 0 when a peer sent a VMCI_TRANSPORT_PACKET_TYPE_RST during the connection handshake. This caused vmci_transport_recv_listen() to skip vsock_remove_pending(), leaving a pending socket on the listener's pending_links while the reference count reached zero. A subsequent write to the freed socket object triggers memory corruption detected by KASAN.

Critical Impact
A local attacker able to trigger the VMCI vsock handshake and issue a peer RST can cause kernel memory corruption, leading to denial of service or potential local privilege escalation.

Affected Products

Linux kernel vsock/vmci transport (multiple stable branches)
Confirmed reproducible on Linux lts-6.12.79 prior to patch
Systems using VMware VMCI vsock communication (guest VMs, hypervisor host interactions)

Discovery Timeline

2026-07-19 - CVE-2026-64115 published to NVD
2026-07-20 - Last updated in NVD database

Technical Details for CVE-2026-64115

Vulnerability Analysis

The defect resides in the VMCI transport code path handling incoming connection state transitions. When vmci_transport_recv_connecting_server() processed a peer RST packet in its default switch arm, it returned success (err = 0) instead of an error. The caller vmci_transport_recv_listen() interpreted this as a normal condition and skipped the cleanup routine vsock_remove_pending(). The pending socket therefore remained linked on pending_links with sk_state = TCP_CLOSE, while the destroy path still released the explicit reference taken before schedule_delayed_work().

One second later, vsock_pending_work() observed is_pending=true and executed full cleanup. It invoked vsock_remove_pending() followed by two sock_put(sk) calls. The first sock_put() drove the refcount to zero and __sk_freed the socket. The second sock_put() then wrote into freed memory, producing the KASAN report slab-use-after-free in refcount_warn_saturate.

Root Cause

The root cause is inconsistent error propagation for unexpected packet types. The conditional err = pkt->type == VMCI_TRANSPORT_PACKET_TYPE_RST ? 0 : -EINVAL; treated an RST as a success case. This desynchronized the listener's pending-list management from the reference-count lifecycle owned by the delayed work handler, producing a double-decrement on the socket reference.

Attack Vector

Exploitation requires local access and the ability to send VMCI vsock packets during the server-side connection handshake. An attacker initiates a connection to a listening vsock endpoint, then transmits a VMCI_TRANSPORT_PACKET_TYPE_RST before the handshake completes. The race between vsock_pending_work() and the missed removal creates the use-after-free window. Successful memory corruption can lead to kernel crash or, with heap grooming, arbitrary kernel memory write and privilege escalation. See the upstream fix at Linux Kernel Commit 1dd531e for the corrected error handling.

Detection Methods for CVE-2026-64115

Indicators of Compromise

KASAN report entries containing slab-use-after-free in refcount_warn_saturate originating from the vsock_pending_work workqueue task.
Kernel oops or panic traces referencing vmci_transport_recv_listen, vsock_pending_work, or sock_put on events workqueue.
Unexpected VMCI vsock connection resets during handshake immediately followed by kernel stability issues.

Detection Strategies

Enable KASAN on test kernels to surface use-after-free conditions in the vsock transport path during fuzzing or QA.
Correlate kernel ring-buffer messages (dmesg) for refcount_warn_saturate warnings tied to vsock_pending_work.
Audit running kernel versions across virtualized hosts and guests to identify unpatched builds exposing the VMCI transport.

Monitoring Recommendations

Ingest /var/log/kern.log and journald kernel facility messages into a centralized logging platform for anomaly review.
Alert on repeated vsock connection failures accompanied by kernel warnings on hosts running VMware guest tools or nested virtualization.
Track vmci module load events and unusual process activity attempting to open AF_VSOCK sockets from unprivileged contexts.

How to Mitigate CVE-2026-64115

Immediate Actions Required

Apply the upstream Linux kernel patch that changes the RST handling to return -EINVAL, forcing synchronous removal from pending_links.
Update to a fixed stable kernel release incorporating the commits referenced in the NVD advisory.
On systems that do not require VMCI vsock, blacklist the vmw_vsock_vmci_transport module to eliminate the attack surface.

Patch Information

The fix treats a peer RST like any other unexpected packet type by returning err = -EINVAL. This ensures all destroy: arms return err < 0, so vmci_transport_recv_listen() removes the pending socket from pending_links synchronously, and vsock_pending_work() takes the is_pending=false / !rejected branch, dropping only its own work reference. Testing on lts-6.12.79 with KASAN moved reproduction from 52/100 unpatched to 0/100 patched. Patch commits are available at Linux Kernel Commit 1dd531e, Linux Kernel Commit 1e19f0, Linux Kernel Commit 440447, Linux Kernel Commit 47e630, Linux Kernel Commit 99e22d, Linux Kernel Commit 9fe74e, Linux Kernel Commit cc27e9, and Linux Kernel Commit ecda37f.

Workarounds

Disable the VMCI vsock transport module on systems that do not require guest-host vsock communication.
Restrict AF_VSOCK socket creation to trusted workloads using seccomp or LSM policies.
Where VMCI is required, minimize local user access and monitor kernel logs for KASAN or refcount warnings until patched kernels are deployed.

bash

# Configuration example: blacklist VMCI vsock transport where not required
echo 'blacklist vmw_vsock_vmci_transport' | sudo tee /etc/modprobe.d/disable-vmci-vsock.conf
echo 'install vmw_vsock_vmci_transport /bin/true' | sudo tee -a /etc/modprobe.d/disable-vmci-vsock.conf
sudo update-initramfs -u
sudo reboot