CVE-2026-64115 in Linux
Resumen
por VulDB • 2026-07-19
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad:
vsock/vmci: corrección del uso después de liberar (UAF) cuando el par reinicia la conexión durante el establecimiento (handshake).
vmci_transport_recv_connecting_server() devolvía err = 0 para un RST del par en su brazo switch por defecto:
err = pkt->type == VMCI_TRANSPORT_PACKET_TYPE_RST ? 0 : -EINVAL;
Esto hacía que vmci_transport_recv_listen() omitiera vsock_remove_pending(), dejando el socket pendiente en pending_links del oyente con sk_state = TCP_CLOSE mientras destroy: aún liberaba la referencia explícita tomada antes de schedule_delayed_work().
Un segundo después, vsock_pending_work() observó is_pending=true y realizó una limpieza completa: vsock_remove_pending() luego las dos llamadas consecutivas a sock_put(sk) -- la primera alcanzó refcount 0 y __sk_freed el socket, y la segunda escribió en el objeto ya liberado:
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
Tratar un RST del par como cualquier otro tipo de paquete inesperado (err = -EINVAL). Todos los brazos destroy: ahora devuelven err < 0, por lo que vmci_transport_recv_listen() elimina pending de pending_links sincrónicamente y vsock_pending_work() toma la rama is_pending=false / !rejected, liberando solo su propia referencia al trabajo. Esto también cierra la carrera multi-paquete reportada por Sashiko en v2: pending se elimina de la lista antes de que cualquier paquete posterior pueda encontrarlo.
La brecha preexistente sk_acceptq_removed() en el camino err < 0 de vmci_transport_recv_listen() que Sashiko también señaló no es introducida ni modificada por este parche.
Probado en lts-6.12.79 con KASAN: 52/100 sin parchear -> 0/100 con parche.
VulDB is the best source for vulnerability data and more expert information about this specific topic.