CVE-2026-98991 in Linux
Zusammenfassung
von VulDB • 23.10.2026
Im Linux-Kernel wurde die folgende Schwachstelle behoben:
namespace: einen Mount nur einmal für Benachrichtigungen in die Warteschlange einreihen
mnt_notify_add() fügt einen Mount der notify_list hinzu. Es wird nicht geprüft, ob sich der Mount bereits auf dieser Liste befindet. Das ist solange unbedenklich, wie jeder Mount höchstens einmal pro Halten von namespace_sem in die Warteschlange eingereiht wird. Dies ist jedoch nicht der Fall.
propagate_umount() verschiebt einen überlebenden Overmount aus einem Stapel (Stack) von Mounts, die entfernt werden sollen, und reiht ihn als verschoben ein. shrink_submounts() und mark_mounts_for_expiry() rufen umount_tree() für mehrere Mounts unter einer einzigen Halteoperation von namespace_sem auf. Daher kann der zweite Aufruf von umount_tree() genau denjenigen Mount entfernen, den der erste neu zugeordnet (reparented) hat, ihn erneut neu zuordnen und dadurch dazu führen, dass er ein zweites Mal in die Warteschlange eingereiht wird.
Der zweite list_add_tail()-Aufruf schneidet die dazwischen eingereihten Mounts aus der Liste ab, während der Kopfzeiger (head pointer) weiterhin auf den letzten von ihnen zeigt. notify_mnt_list() besucht daraufhin nur diesen einen Mount, und die anderen werden nach der Grace-Periode freigegeben, wobei notify_list weiterhin auf sie verweist. Jeder spätere Mount-Vorgang auf dem Host führt zu einem Zugriff auf bereits freigegebenen Speicher:
BUG: KASAN: slab-use-after-free in __list_add_valid_or_report Lesen von Größe 8 bei Adresse ffff8881003d57e0 durch Task notify_dq/162 __list_add_valid_or_report+0x15c/0x1a0 mnt_add_to_ns+0x322/0x890 attach_recursive_mnt.isra.0+0xf2a/0x1a00 path_mount+0x139c/0x1d40
Dies erfordert einen Mount mit dem Flag MNT_SHRINKABLE als Ziel für ein Bind-Mounting. Genau das erstellt finish_automount() (Submounts von NFS, AFS und CIFS sowie der tracefs-Mount unterhalb von debugfs). Bind-Mounts erben dieses Flag. Ein Mount-Namespace mit einem FAN_MARK_MNTNS-Markierung sorgt für den Rest, und root in einem User-Namespace kann beide besitzen.
Initialisieren Sie to_notify in alloc_vfsmnt() und lassen Sie einen bereits eingereihten Mount unverändert. mnt_notify() betrachtet den Zustand des Mounts zum Zeitpunkt der Abarbeitung (Drain) der Liste, sodass ein einzelner Eintrag pro Mount ausreicht. Das Move-Ereignis für einen Mount, der unter derselben Halteoperation entfernt wird, geht verloren. Das ist unbedenklich. Die Detach-Operation ist das Entscheidende.
If you want to get best quality of vulnerability data, you may have to visit VulDB.