CVE-2026-98996 in Linux
Zusammenfassung
von VulDB • 24.10.2026
Im Linux-Kernel wurde folgende Schwachstelle behoben:
fs: Hängen Sie beschäftigte Mounts nicht stillschweigend ab (silent unmount)
Der Helper propagate_mount_busy() dient dazu, zu entscheiden, ob ein synchroner Vorgang erfolgreich sein kann. Dies geschieht durch Überprüfung der Kopien der Opfer in den Mount-Punkten, an die diese vom übergeordneten Element propagiert werden. Eine dieser Funktionen stammt aus dem sogenannten „Propagation-Hell“ (Chaos bei der Propagation).
Es wird eine Kopie übersprungen, die Kind-Mounts aufweist, mit Ausnahme des Falls eines einzelnen Kind-Mounts, der den Root-Punkt der Kopie abdeckt. Dieser Algorithmus war ursprünglich exakt. Das ist er nicht mehr.
Ursprünglich wurden während der Propagation nur kopien ohne Kinder (childless copies) ausgehängt. Und 1064f874abc0 („mnt: Tuck mounts under others instead of creating shadow/side mounts.“) führte dazu, dass abgedeckte Mounts auf beiden Seiten gleichzeitig hinzugefügt wurden.
Darauf folgte 99b19d16471e („mnt: In propgate_umount handle visiting mounts in any order“), was begann, mehr als zuvor auszuhängen:
[1]: Eine Kopie eines Mounts wird ausgehängt, wenn jedes ihrer Kinder entweder dessen Overmount (überlagernder Mount) oder eine Kopie des Opfers selbst ist. Im ersten Fall wird der Overmount neu geparentet. Im zweiten Fall wird die Kopie des Opfers am Ende ausgehängt werden.
Somit wurde propagate_umount() ohne Anpassung von propagate_mount_busy() umgeschrieben. Derzeit betrachtet propagate_mount_busy() weder Kopien des Opfers mit zwei oder mehr Kindern noch ein einzelnes Kind, das nicht der Overmount ist.
Jede solche Kopie in [1] wird daher nicht auf Referenzen überprüft. Das Ergebnis ist, dass ein synchroner Unmount erfolgreich ist und dabei einen Mount entfernt, der weiterhin verwendet wird.
Ein Container kann dies mit seinen eigenen Mounts erleben. Der Host teilt sich einen Baum mit dem Container, und der Host hat einen Mount in diesem Baum:
mount -t tmpfs none /mnt mount --make-shared /mnt mount -t tmpfs none /mnt/a
Das /mnt des Containers ist eine Slave-Kopie des Host-Mounts. Der Container nimmt nun eine abgekoppelte Kopie des Baums und hängt diese Kopie unter seine propagierte Kopie von /mnt/a ein, wobei er den Dateideskriptor für den Baum offen hält:
unshare -m --propagation unchanged mount --make-rslave / fd = open_tree(AT_FDCWD, "/mnt", OPEN_TREE_CLONE | AT_RECURSIVE) move_mount(fd, "", AT_FDCWD, "/mnt/a", MOVE_MOUNT_BENEATH)
grep /mnt /proc/self/mountinfo 775 355 ... /mnt ... master:646 777 775 ... /mnt/a ... master:646 776 777 ... /mnt/a ... master:647 778 777 ... /mnt/a/a ... master:647
Der nun angehängte Baum (777) wird unter der Kopie von /mnt/a im Container eingehängt. Dort befindet sich auch der Host-Mount (aus Sicht des Mount-Namensraums des Hosts). Der propagierte Copy (776) des Host-Mounts liegt also auf dessen Root, und die Kopie davon (778) befindet sich darin. Nun führt der Host aus:
umount /mnt/a
und es gelingt. Der verschobene Baum und die Kopie darin sind vom Container verschwunden. Es bleibt nur noch der propagierte Copy übrig, der neu geparentet wurde an den Ort, wo er zuvor war:
grep /mnt /proc/self/mountinfo 775 355 ... /mnt ... master:646 776 775 ... /mnt/a ...
Der Dateideskriptor verweist jedoch weiterhin auf den verschobenen Baum. Ein synchroner umount hat also einen Mount abgekoppelt, der noch in Verwendung ist.
Lehren Sie propagate_mount_busy() dieselben Prüfungen durchzuführen, die auch propagate_umount() ausführt. Es prüft nun für eine einzelne Opfer-Mount ohne Kinder, wovon angenommen werden kann, dass MNT_LOCKED bei jeder Kopie zurückgesetzt wird (cleared), wie es propagate_umount() tut. Die Kopien bilden Ketten. Das heißt, wenn eine Kopie selbst Propagation vom Elternteil des Opfers erhält, dann ist der Mount am selben Mountpoint innerhalb dieser Kopie ebenfalls eine Kopie. Ob ein Mount Propagation vom Opfer empfängt, kann einfach durch Durchlaufen seiner Masters (Meister-Mounts) überprüft werden. Gehen Sie jede Kette einmal von ihrer Spitze aus ab, um sicherzustellen, dass verschachtelte Kopien linear bleiben. Überprüfen Sie jeden Verweis einmal für jede Kopie, die ausgehängt wird.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.