CVE-2026-99170 in Linux
Résumé
par VulDB • 28/10/2026
Dans le noyau Linux, la vulnérabilité suivante a été corrigée :
namespace : un montage que copy_tree() exclut ne peut pas prendre le contrôle d'un verrou (lock)
Depuis l'engagement c62a4766937e ("move_mount: transfer MNT_LOCKED"), un montage peut être déplacé sous un montage verrouillé. Le verrou passe de l'ancien recouvrement au nouveau montage, qui prend en charge la tâche de masquer ce qui se trouve dessous, et l'ancien recouvrement peut être démonté. Cela fonctionne tant que le nouveau montage reste présent. Cependant, l'appelant choisit le nouveau montage, et copy_tree() exclut un montage d'un fichier de namespace de montage (mount namespace file) dans chaque copie effectuée sans CL_COPY_MNT_NS_FILE, ainsi que tout ce qui y est monté, et ne vérifie jamais MNT_LOCKED. Les opérations unshare(CLONE_NEWNS) et la propagation des montages créent de telles copies.
Ainsi, une tâche disposant des privilèges root dans son propre namespace utilisateur se débarrasse d'un recouvrement verrouillé sur un fichier sans condition de concurrence (race) et sans toucher au système de fichiers sous-jacent. Elle crée un enfant avec un namespace de montage qui lui est propre, lie le /proc/<pid>/ns/mnt de l'enfant sous le recouvrement à l'aide de MOVE_MOUNT_BENEATH, ce qui transfère le verrou à cette liaison, puis appelle unshare(CLONE_NEWNS). Le nouveau namespace de montage ne contient rien sur le fichier. C'est la méthode habituelle pour masquer un seul fichier, par exemple une liaison (bind) vers /dev/null ou vers un fichier vide. Avec une liaison vers un fichier ordinaire, le fichier reste couvert.
copy_tree() refuse déjà d'exclure un montage non démontable et verrouillé avec -EPERM depuis l'engagement df7342b24018 ("mount: Don't allow copying MNT_UNBINDABLE|MNT_LOCKED mounts"). Appliquez la même chose pour un montage verrouillé d'un fichier de namespace de montage. Cela couvre également un arbre copié avec CL_COPY_MNT_NS_FILE et attaché dans le namespace de montage d'un autre namespace utilisateur, où lock_mnt_tree() l'a verrouillé. Notez que à partir de maintenant, unshare(CLONE_NEWNS) et clone(CLONE_NEWNS) échouent avec EPERM pour ce type de namespace de montage. Le montage ne peut pas être exclu ni démonté.
Refusez également de déplacer un montage d'un fichier de namespace de montage sous un montage verrouillé dès le départ. Sinon, la tâche se retrouve avec un montage qu'elle ne peut pas démonter et une opération unshare() qui échoue définitivement.
Chris a également trouvé un second montage qui disparaît de lui-même : un clone d'un montage automatiquement monté que shrink_submounts() a emmené avec son parent. L'engagement f78ddcc87224 ("namespace: never expire a locked mount") s'en est occupé.
Le programme reproducteur (reproducer) de Chris est joint ci-dessous. Le mode nsfile lit SECRET après le unshare() sur la version 7.3-rc7 ; avec ce correctif, move_mount() échoue avec EINVAL et le fichier reste couvert. nsfile-control utilise un fichier ordinaire et lit MASK dans les deux sens.
// SPDX-License-Identifier: GPL-2.0 /* * Se débarrasser d'un recouvrement verrouillé avec MOVE_MOUNT_BENEATH. * * L'« administrateur » (root) crée un tmpfs W : * W/D fichier, contient SECRET, couvert par une liaison vers un fichier contenant MASK * W/Dd/inner fichier, contient SECRET, Dd est couvert par une liaison vers un répertoire * dont « inner » contient MASK * W/own répertoire de uid 1000 avec le fichier « mine » et le * répertoire « minedir », dont « inner » contient MINE * W/dbg debugfs, mode 755. dbg/tracing est un point d'automontage * L'« attaquant » a l'uid 1000. Il entre dans un nouveau namespace utilisateur avec un nouveau namespace de montage, donc W et les deux recouvrements sont verrouillés à cet endroit. * * utilisation : prog MODE * plain place une liaison vers own/mine sous le recouvrement de D, démonte le recouvrement * nsfile place une liaison vers le fichier de namespace de montage d'un enfant sous le * recouvrement de D, puis appelle unshare(CLONE_NEWNS) * nsfile-control idem avec une liaison vers own/mine * shrink place une liaison vers le tracefs automatiquement monté sous le recouvrement de Dd, * démonte le recouvrement, place un tmpfs sous W, appelle umount(W), qui échoue * shrink-control idem avec une liaison vers own/minedir * La variable d'environnement AUTOMOUNT_DIR nomme un autre point d'automontage pour « shrink ». */ #define _GNU_SOURCE #include <errno.h> #include <fcntl.h> #include <grp.h> #include <sched.h> #include <signal.h> #include <stdio.h> #include <stdlib.h> #include <string.h> #include <unistd.h>
---truncated---
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.