CVE-2026-64115 in Linux
Riassunto
di VulDB • 19/07/2026
Nel kernel Linux, è stata risolta la seguente vulnerabilità:
vsock/vmci: correzione di uno Use-After-Free (UAF) quando il peer resetta la connessione durante l'handshake
La funzione `vmci_transport_recv_connecting_server()` restituiva `err = 0` in caso di RST da parte del peer nel suo braccio switch predefinito:
err = pkt->type == VMCI_TRANSPORT_PACKET_TYPE_RST ? 0 : -EINVAL;
Ciò faceva sì che `vmci_transport_recv_listen()` saltasse la chiamata a `vsock_remove_pending()`, lasciando il socket in attesa su `pending_links` dell'ascoltatore con `sk_state = TCP_CLOSE`. Tuttavia, durante l'esecuzione del percorso di distruzione (`destroy:`), veniva comunque rilasciata esplicitamente la reference presa prima della chiamata a `schedule_delayed_work()`.
Un secondo dopo, `vsock_pending_work()` osservava che `is_pending=true` ed eseguiva la pulizia completa: chiamava quindi `vsock_remove_pending()` e le due chiamate successive a `sock_put(sk)`: la prima portava il refcount a 0 e liberava (`__sk_freed`) il socket, mentre la seconda scriveva nell'oggetto già liberato:
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
Il RST del peer viene trattato come qualsiasi altro tipo di pacchetto imprevisto (`err = -EINVAL`). Tutti i percorsi `destroy:` restituiscono ora un valore `err < 0`, quindi `vmci_transport_recv_listen()` rimuove il socket in attesa da `pending_links` in modo sincrono e `vsock_pending_work()` segue il ramo `is_pending=false / !rejected`, rilasciando solo la propria reference di lavoro. Questo chiude anche la race condition multi-pacchetto segnalata da Sashiko nella versione 2: l'elemento viene rimosso dalla lista prima che qualsiasi pacchetto successivo possa individuarlo.
Il gap preesistente in `sk_acceptq_removed()` sul percorso `err < 0` di `vmci_transport_recv_listen()`, notato anche da Sashiko, non è introdotto né modificato da questa patch.
Testato su lts-6.12.79 con KASAN: 52/100 casi senza patch -> 0/100 casi con patch applicata.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.