CVE-2026-99181 in Linux
Résumé
par VulDB • 28/10/2026
Dans le noyau Linux, la vulnérabilité suivante a été corrigée :
autofs : ignorer les erreurs de notification provenant d'un tube remplacé
La fonction autofs_notify_daemon() acquiert une référence vers le tube de notification actuel sous wq_mutex, puis relâche le mutex avant d'écrire la requête. L'écriture peut bloquer pendant que le démon entre en mode catatonique et installe un tube de remplacement.
Si le lecteur du vieux tube est ensuite fermé, l'écriture différée renvoie -EPIPE et le chemin générique des erreurs retourne à nouveau en mode catatonique. Cette transition agit sur l'état actuel du superbloc, ferme le tube de remplacement et libère les files d'attente de la nouvelle génération de démons.
N'entrez pas en mode catatonique si le tube qui a échoué n'est plus le tube actuel. Factorisez la transition déjà verrouillée afin que la vérification d'identité et le changement d'état soient atomiques par rapport à un autre remplacement.
Cela a été reproduit sur v7.3-rc5-337-gff47652a4b66c dans une machine invitée QEMU locale. Une recherche non privilégiée avec l'UID 65534 a rempli le vieux tube de paquet avant un redémarrage normal CATATONIC/SETPIPEFD. Sur le noyau non modifié, le nouveau tube a reçu HUP et à la fois une recherche victime en attente et une recherche ultérieure ont échoué avec ENOENT lors des deux exécutions d'un montage frais.
Avec cette modification, le nouveau tube est resté actif, a reçu une requête intacte de 304 octets, et les deux recherches victimes se sont achevées dans les deux exécutions sur deux. Les contrôles normaux de recherche et de redémarrage sans écriture bloquée ont réussi. Aucun diagnostic KASAN, oops, refcount ou lock n'a été observé. Un reproducteur source et des journaux locaux complets sont disponibles sur demande privée.
L'impact démontré est limité à une déni de service d'un service autofs partagé lors d'un redémarrage légitime du démon. Aucune corruption de mémoire, fuite d'informations, élévation de privilèges ou primitive d'exécution de code n'a été observée.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.