CVE-2026-64115

Linux kernel (GCP) vulnerabilities

Beschreibung

Im Linux-Kernel wurde die folgende Schwachstelle behoben:

vsock/vmci: Behebung von UAF, wenn der Peer während des Handshakes die Verbindung zurücksetzt

vmci_transport_recv_connecting_server() gab err = 0 für einen Peer RST in seinem Standard-Switch-Arm zurück:

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

Dies führte dazu, dass vmci_transport_recv_listen() vsock_remove_pending() übersprang und das anstehende Socket im pending_links des Listeners mit sk_state = TCP_CLOSE zurückließ, während destroy: die explizite Referenz, die vor schedule_delayed_work() genommen wurde, weiterhin freigab.

Eine Sekunde später beobachtete vsock_pending_work(), dass is_pending=true war und führte eine vollständige Bereinigung durch: vsock_remove_pending() gefolgt von den beiden nachfolgenden sock_put(sk)-Aufrufen – der erste erreichte einen Refcount von 0 und __sk_freed das Socket, und der zweite schrieb in das freigegebene Objekt:

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

Behandle Peer RST wie jede andere unerwartete Pakettyp (err = -EINVAL). Alle destroy:-Arme geben nun err < 0 zurück, so dass vmci_transport_recv_listen() synchron pending aus pending_links entfernt und vsock_pending_work() den is_pending=false / !rejected-Zweig nimmt, wodurch nur seine eigene Arbeitreferenz freigegeben wird. Dies schließt auch das von Sashiko gemeldete Mehr-Paket-Rennen in v2: pending wird aus der Liste entfernt, bevor ein nachfolgendes Paket es finden kann.

Der bestehende sk_acceptq_removed()-Lücke auf dem err < 0-Pfad von vmci_transport_recv_listen(), die Sashiko ebenfalls bemerkte, wird durch diesen Patch weder eingeführt noch geändert.

Getestet auf lts-6.12.79 mit KASAN: 52/100 unpatched -> 0/100 patched.