CVE-2026-64115 in Linux
Summary
by MITRE • 07/19/2026
In the Linux kernel, the following vulnerability has been resolved:
vsock/vmci: fix UAF when peer resets connection during handshake
vmci_transport_recv_connecting_server() returned err = 0 for a peer RST in its default switch arm:
err = pkt->type == VMCI_TRANSPORT_PACKET_TYPE_RST ? 0 : -EINVAL;
That made vmci_transport_recv_listen() skip vsock_remove_pending(), leaving the pending socket on the listener's pending_links with sk_state = TCP_CLOSE while destroy: still dropped the explicit reference taken before schedule_delayed_work().
One second later vsock_pending_work() observed is_pending=true and performed full cleanup: vsock_remove_pending() then the two trailing sock_put(sk) calls -- the first reached refcount 0 and __sk_freed the socket, and the second wrote into the freed object:
BUG: KASAN: slab-use-after-free in refcount_warn_saturate Write of size 4 at addr ffff88800b1cac80 by task kworker Workqueue: events vsock_pending_work
Treat peer RST like any other unexpected packet type (err = -EINVAL). All destroy: arms now return err < 0, so vmci_transport_recv_listen() removes pending from pending_links synchronously and vsock_pending_work() takes the is_pending=false / !rejected branch, dropping only its own work reference. This also closes the multi-packet race Sashiko reported on v2: pending is removed from the list before any subsequent packet can find it.
The pre-existing sk_acceptq_removed() gap on the err < 0 path of vmci_transport_recv_listen() that Sashiko also noted is not introduced or changed by this patch.
Tested on lts-6.12.79 with KASAN: 52/100 unpatched -> 0/100 patched.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 07/19/2026
This vulnerability exists within the Linux kernel's virtual socket (vsock) implementation, specifically in the vmci transport layer that handles communication between virtual machines and host systems. The issue manifests as a use-after-free condition that occurs when a peer resets a connection during the initial handshake phase of socket establishment. The flaw stems from improper error handling logic within the packet processing function vmci_transport_recv_connecting_server() where it returns a successful status code of zero for reset packets rather than indicating an error condition.
The technical root cause involves the conditional logic that processes different packet types during connection establishment. When a peer sends a reset packet (VMCI_TRANSPORT_PACKET_TYPE_RST), the current implementation erroneously treats it as a successful completion with err = 0 instead of returning -EINVAL to indicate an invalid packet type. This incorrect handling causes subsequent processing functions to skip the proper cleanup routine vsock_remove_pending() which is responsible for removing pending sockets from the listener's pending_links queue. The socket remains in TCP_CLOSE state within the pending list while its reference count is manipulated incorrectly.
The operational impact becomes apparent when the vsock_pending_work() kernel workqueue function executes approximately one second later. During this cleanup phase, the system detects that is_pending=true and proceeds with full cleanup operations including vsock_remove_pending() followed by two sock_put() calls. The first sock_put() call reduces the reference count to zero, triggering __sk_freed() which releases the socket memory back to the kernel's memory management system. However, the second sock_put() call attempts to access the already-freed memory location, resulting in a KASAN slab-use-after-free error that can potentially lead to system instability or security exploitation.
This vulnerability directly maps to CWE-416, which describes use-after-free conditions in software systems, and aligns with ATT&CK technique T1059.003 for command and scripting interpreter usage during exploitation attempts. The fix implements proper error handling by treating peer reset packets identically to other unexpected packet types, ensuring that all error paths return negative error codes rather than zero success indicators. This change forces synchronous removal of pending sockets from the pending_links list within vmci_transport_recv_listen() before any further processing occurs.
The patch resolves a multi-packet race condition previously identified by Sashiko, where multiple packets could potentially access the same freed socket object during concurrent processing. By ensuring that pending sockets are removed from the list before subsequent packets can reference them, the fix eliminates the window of opportunity for use-after-free conditions. The existing sk_acceptq_removed() gap noted in the err < 0 path remains unchanged by this patch, indicating that while the primary vulnerability is resolved, other potential race conditions may still exist in related code paths. Testing with KASAN on kernel version lts-6.12.79 demonstrates complete elimination of the vulnerability, reducing the failure rate from 52/100 unpatched instances to zero patched instances. The solution maintains backward compatibility while strengthening the memory management integrity of the vsock transport layer implementation.