CVE-2026-64115 in Linux
Résumé
par VulDB • 20/07/2026
Dans le noyau Linux, la vulnérabilité suivante a été corrigée :
vsock/vmci : correction d’un Use-After-Free (UAF) lorsque l’extrémité distante réinitialise la connexion pendant la phase de négociation (handshake).
La fonction `vmci_transport_recv_connecting_server()` renvoyait `err = 0` en cas de RST provenant du pair dans son bras par défaut :
err = pkt->type == VMCI_TRANSPORT_PACKET_TYPE_RST ? 0 : -EINVAL;
Cela amenait `vmci_transport_recv_listen()` à ignorer l’appel à `vsock_remove_pending()`, laissant le socket en attente sur les `pending_links` de l’écouteur avec un état `sk_state = TCP_CLOSE`. Cependant, la branche `destroy:` supprimait toujours explicitement la référence prise avant l’appel à `schedule_delayed_work()`.
Une seconde plus tard, `vsock_pending_work()` observait que `is_pending=true` et effectuait le nettoyage complet : appel de `vsock_remove_pending()` suivi des deux appels consécutifs à `sock_put(sk)` — le premier faisant passer le compteur de références (`refcount`) à 0 et libérant ainsi le socket via `__sk_freed`, tandis que le second écrivait dans l’objet déjà libéré :
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
Le RST provenant du pair est désormais traité comme tout autre type de paquet inattendu (`err = -EINVAL`). Toutes les branches `destroy:` renvoient maintenant une valeur négative pour `err`, ce qui permet à `vmci_transport_recv_listen()` de supprimer l’entrée des `pending_links` de manière synchrone, et amène `vsock_pending_work()` à emprunter la branche `is_pending=false / !rejected`, ne libérant ainsi que sa propre référence liée au travail. Cela résout également une condition de course multi-paquets signalée par Sashiko dans la version 2 : l’entrée est supprimée de la liste avant qu’un paquet ultérieur puisse y accéder.
L’écart préexistant concernant `sk_acceptq_removed()` sur le chemin `err < 0` de `vmci_transport_recv_listen()`, également noté par Sashiko, n’est ni introduit ni modifié par ce correctif.
Testé avec la version lts-6.12.79 sous KASAN : passage de 52/100 cas non corrigés à 0/100 après application du correctif.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.