CVE-2026-64115

In the Linux kernel, the following vulnerability has been resolved:

vsock/vmci: fix UAF when peer resets connection during handshake

vmcitransportrecvconnectingserver() returned err = 0 for a peer RST in its default switch arm:

err = pkt->type == VMCI_TRANSPORT_PACKET_TYPE_RST ? 0 : -EINVAL;

That made vmcitransportrecvlisten() skip vsockremovepending(), leaving the pending socket on the listener's pendinglinks with skstate = TCPCLOSE while destroy: still dropped the explicit reference taken before scheduledelayedwork().

One second later vsockpendingwork() observed ispending=true and performed full cleanup: vsockremovepending() then the two trailing sockput(sk) calls -- the first reached refcount 0 and _skfreed the socket, and the second wrote into the freed object:

BUG: KASAN: slab-use-after-free in refcountwarnsaturate Write of size 4 at addr ffff88800b1cac80 by task kworker Workqueue: events vsockpendingwork

Treat peer RST like any other unexpected packet type (err = -EINVAL). All destroy: arms now return err < 0, so vmcitransportrecvlisten() removes pending from pendinglinks synchronously and vsockpendingwork() 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 skacceptqremoved() gap on the err < 0 path of vmcitransportrecv_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.