CVE-2026-64115

What it actually does

This is a Linux kernel use-after-free in the VMCI-backed virtio/vsock connection handshake path. When a peer resets a connection during the server-side handshake, the vulnerable code can leave a pending socket linked on the listener queue while also dropping references that allow the socket object to be freed. A delayed work item later treats the stale socket as still pending and performs cleanup again, causing writes to freed kernel memory. Because the flaw occurs in kernel memory management, successful exploitation can potentially lead to local privilege escalation, kernel memory corruption, information disclosure, or denial of service through a kernel crash.

Why it matters to the business

Systems that expose or use Linux vsock/VMCI functionality, especially virtualized Linux workloads, may be at risk from a local authenticated attacker or malicious workload able to interact with vsock sockets. The practical business risk is that an attacker who already has local code execution with limited privileges could destabilize the host or guest kernel and may be able to escalate privileges, compromise sensitive data, or interrupt services. The CVSS score is high, but current public exploitation signals are low: EPSS is 0.00135, it is not listed in CISA KEV, and no known ransomware use is indicated.

How an attack unfolds

An attacker first obtains local code execution on a Linux system where the vulnerable kernel code and VMCI/vsock transport are available. They then create or interact with AF_VSOCK/VMCI connections in a way that places a socket into the listener pending queue during the connection handshake. During that handshake, the attacker causes the peer side to send or trigger a reset packet at the vulnerable timing window. In affected kernels, the reset is treated as a successful condition instead of an error, so the pending socket is not synchronously removed from the listener's pending list while its references are still dropped. After the delayed pending work runs, the kernel sees the stale pending socket and attempts cleanup again, writing to memory that may already have been freed. Depending on allocator state, kernel hardening, and exploit reliability, this may result in a crash or potentially controlled kernel memory corruption useful for privilege escalation.

How to fix it

Apply a Linux kernel update that includes the fix for the VMCI/vsock handshake reset handling bug. Because no product-specific fixed versions were provided, use the relevant vendor kernel advisory for the distribution, hypervisor-integrated kernel, appliance, or embedded Linux build in use. Prioritize kernels used in virtualized environments and systems that support AF_VSOCK/VMCI communication. If immediate patching is not possible, reduce exposure by disabling or unloading unused VMCI/vsock-related kernel modules where operationally safe, restricting local shell access, limiting untrusted workloads, and applying kernel hardening controls such as unprivileged user restrictions, SELinux/AppArmor confinement, and rapid reboot/rollback procedures for kernel crashes.

How to confirm the fix worked

Confirm that the running kernel includes the upstream or vendor backport that changes peer RST handling in vmci_transport_recv_connecting_server() to return an error and remove pending sockets synchronously. Validate by checking the running kernel package version against the vendor advisory, not just the installed package list, because a reboot is normally required after a kernel update. On Linux, compare `uname -a` and package manager output such as `rpm -q kernel`, `dpkg -l 'linux-image*'`, or the distribution-specific livepatch status. Where source or build metadata is available, verify that the VMCI/vsock patch is present. For exposure validation, check whether vsock/VMCI modules are loaded with `lsmod | grep -E 'vsock|vmci'`, whether AF_VSOCK is supported, and whether workloads legitimately depend on it before disabling mitigations.

Typical attack path

1. Gain local code execution with low privileges on a Linux system where VMCI/vsock transport is enabled or reachable.
2. Create or target a vsock listener and initiate a VMCI/vsock connection handshake.
3. Trigger a peer reset during the vulnerable handshake state so the pending socket is left on the listener pending list.
4. Wait for the delayed vsock pending work item to process the stale socket.
5. Leverage the resulting use-after-free for kernel crash, memory corruption, or potential privilege escalation.

How to detect it

There are no universally reliable network IOCs for this issue because exploitation is local and abuses kernel socket behavior rather than a distinctive remote payload. To look for prior exploitation, review kernel logs and persistent journal data using `journalctl -k`, `dmesg`, `/var/log/kern.log`, `/var/log/messages`, `/var/log/syslog`, and crash dump facilities such as kdump, apport, ABRT, or systemd-coredump. Search for KASAN, kernel oops, panic, refcount, slab use-after-free, and stack traces involving `vsock_pending_work`, `vmci_transport_recv_connecting_server`, `vmci_transport_recv_listen`, or `vsock_remove_pending`. Correlate those events with local user sessions, container activity, recently executed binaries, and audit/EDR telemetry showing unusual creation of AF_VSOCK sockets or repeated failures around virtual socket communication. If KASAN is not enabled, exploitation may only appear as a kernel panic, general protection fault, refcount warning, soft lockup, or unexplained reboot, so absence of the exact KASAN string does not rule out attempted exploitation.

• BUG: KASAN: slab-use-after-free in refcount_warn_saturate
• slab-use-after-free in refcount_warn_saturate
• Workqueue: events vsock_pending_work
• vsock_pending_work
• vmci_transport_recv_connecting_server
• vmci_transport_recv_listen
• vsock_remove_pending
• __sk_free
• __sk_freed
• sk_state = TCP_CLOSE
• VMCI_TRANSPORT_PACKET_TYPE_RST
• refcount_warn_saturate
• kernel BUG at
• general protection fault
• Kernel panic - not syncing
• KASAN: slab-use-after-free

What your security team should do

• Prioritize patching or live-patching affected Linux kernels on virtualized systems and hosts/guests that use VMCI or vsock communication.
• Inventory systems with loaded vsock/VMCI modules or workloads that use AF_VSOCK, then rank them ahead of systems where the functionality is absent or disabled.
• Reboot systems after kernel package updates unless a verified livepatch fully remediates the vulnerable code path.
• If patching is delayed, disable unused VMCI/vsock functionality where feasible and enforce least privilege for local users and workloads.
• Monitor kernel logs, crash dumps, and EDR telemetry for signs of vsock-related kernel faults, KASAN reports, or suspicious local processes exercising AF_VSOCK heavily.
• Treat unexplained kernel crashes on systems with vsock/VMCI enabled as potentially security-relevant until crash dumps and logs are reviewed.
• Track vendor advisories for exact fixed kernel versions and backports because Linux distributions may remediate this in kernels with version numbers that differ from upstream.