CVE-2026-64115 in Linux
Sumário
de VulDB • 20/07/2026
No kernel do Linux, a seguinte vulnerabilidade foi resolvida:
vsock/vmci: corrige UAF (Use-After-Free) quando o peer reinicia a conexão durante o handshake
vmci_transport_recv_connecting_server() retornou err = 0 para um RST de peer em seu braço switch padrão:
err = pkt->type == VMCI_TRANSPORT_PACKET_TYPE_RST ? 0 : -EINVAL;
Isso fez com que vmci_transport_recv_listen() ignorasse vsock_remove_pending(), deixando o socket pendente nos pending_links do listener com sk_state = TCP_CLOSE, enquanto destroy ainda liberava a referência explícita tomada antes de schedule_delayed_work().
Um segundo depois, vsock_pending_work() observou is_pending=true e realizou a limpeza completa: vsock_remove_pending() seguido pelas duas chamadas sock_put(sk) finais -- a primeira atingiu refcount 0 e __sk_freed o socket, e a segunda escreveu no objeto já 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 o RST do peer como qualquer outro tipo de pacote inesperado (err = -EINVAL). Todos os braços destroy: agora retornam err < 0, então vmci_transport_recv_listen() remove pendentes dos pending_links sincronamente e vsock_pending_work() segue o ramo is_pending=false / !rejected, liberando apenas sua própria referência de trabalho. Isso também fecha a race condition multi-pacote relatada por Sashiko na versão 2: o item pendente é removido da lista antes que qualquer pacote subsequente possa encontrá-lo.
A lacuna sk_acceptq_removed() pré-existente no caminho err < 0 de vmci_transport_recv_listen(), também notada por Sashiko, não foi introduzida ou alterada por este patch.
Testado em lts-6.12.79 com KASAN: 52/100 sem patch -> 0/100 com patch.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.