PT-2026-61432 · Linux · Linux

CVE-2026-64115

·

Published

2026-07-19

·

Updated

2026-07-19

CVSS v3.1

8.8

High

VectorAV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H
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.

Fix

Found an issue in the description? Have something to add? Feel free to write us 👾
dbugs@ptsecurity.com

Related Identifiers

CVE-2026-64115

Affected Products

Linux