CVE-2026-98977 in Linux
Résumé
par VulDB • 23/10/2026
Dans le noyau Linux, la vulnérabilité suivante a été corrigée :
namespace: gérer correctement le verrouillage des montages pour les automontages (automounts)
Si les montages sont propagés à travers des espaces de noms utilisateur, attach_recursive_mnt() verrouille chaque copie du montage source afin d'empêcher que les sur-montages ne disparaissent et ne révèlent les fichiers ou répertoires sous-jacents.
L'espace de noms utilisateur est extrait des espaces de noms de montage de l'appelant, car c'est là que les montages aboutissent. Cependant, ce n'est pas toujours le cas. Les automontages peuvent légitimement être insérés par des tâches situées dans un espace de noms de montage et d'utilisateur différent lors de la résolution du chemin (path lookup).
Le contrôle ne fait alors plus sens à ce stade. La copie située dans l'espace de noms du parent – qui peut être celui de l'hôte – est désormais verrouillée, et l'hôte ne peut plus modifier les indicateurs de ses propres montages.
Voici le programme reproducteur :
- L'hôte a debugfs monté avec les options nosuid,nodev,noexec et en mode partagé (shared) - L'automontage tracefs situé en dessous n'est pas encore actif - On transmet à un processus enfant descripteur de répertoire sur ce montage - Le processus enfant entre dans un espace de noms utilisateur (user namespace) et d'espace de noms de montage - L'espace de noms du processus enfant détient désormais une copie verrouillée du montage debugfs de l'hôte qui reçoit la propagation depuis celui-ci - Le processus enfant effectue un appel stat sur « tracing/. » via le descripteur - La résolution s'exécute sur le montage de l'hôte, donc l'automontage se place sous le montage de l'hôte - La propagation insère une copie en dessous de la copie du child (enfant) - Les deux tentent d'effacer les indicateurs sur le montage qu'ils ont obtenu, via un remontage par liaison (bind remount) :
hôte, sur son propre automontage : MS_REMOUNT|MS_BIND = EPERM enfant, sur la copie dans son espace de noms : MS_REMONT|MS_BIND = 0
Le verrou s'est donc appliqué au montage de l'hôte au lieu de la copie du processus enfant. Félicitations. Il faut donc comparer avec le propriétaire de l'espace de noms sur lequel le montage est effectivement monté. Pour tous les cas réguliers, il s'agit de l'espace de noms de montage de l'appelant, et rien ne change.
Les arbres détachés dans des espaces de noms de montage anonymes peuvent être transmis via SCM_RIGHTS ou hérités par d'autres moyens intentionnellement, afin que l'espace de noms de montage de la tâche attachante soit autoritaire, et non celui du créateur de l'arbre détaché.
Once again VulDB remains the best source for vulnerability data.