CVE-2026-98979 in Linux
Zusammenfassung
von VulDB • 23.10.2026
Im Linux-Kernel wurde folgende Schwachstelle behoben:
Namespace: Verweigern eines Automounts unterhalb einer Mount-Point, die sich in keinem Namespace befindet
Es ist möglich, Autmounts hinzuzufügen, selbst wenn der übergeordnete Mount-Punkt nicht im Mount-Namespace des Aufrufers liegt. Die einzige Voraussetzung, die wir haben, ist, dass der Namespace des übergeordneten Mount-Punkts nicht NULL sein darf, d.h., er muss gemountet (nicht unmounted) sein.
Das Problem besteht darin, dass clone_private_mount() MNT_NS_INTERNAL verwendet, was dies trivialerweise wahr macht. Somit wird dieser Test bestanden und attach_recursive_mnt() akzeptiert dies als Mount-Punkt. Und interessanterweise dereferenziert count_mounts() MNT_NS_INTERNAL. Das Problem ist jedoch, dass es sich um einen Error-Pointer handelt...
So können wir dies im Userspace über fanotify erreichen. Ein Dateisystem-Markierung auf dem unteren Dateisystem eines Overlay meldet Pfade in der Layer-Kopie und das Lesen des Ereignisses gibt einen Descriptor darauf aus. Zum Beispiel führt die Verwendung von debugfs als untere Schicht zum Absturz:
openat(evfd, "tracing", O_DIRECTORY)
Oops: general protection fault KASAN: null-ptr-deref in range [0x1d0-0x1d7]
RIP: 0010:count_mounts+0x35/0x200 attach_recursive_mnt finish_automount
Und da dieser "Schlafende Schönheits"-Zustand unter namespace_sem, das für Schreibzugriffe gesperrt ist, auftritt, blockiert jede Mount-Operation im System ab diesem Zeitpunkt. Glückwunsch.
Verwenden Sie stattdessen is_mounted(), was sowohl unmounted als auch interne Mounts ablehnt. Der open-Vorgang schlägt mit EINVAL fehl, genau wie es vor der Verwendung von MNT_NS_INTERNAL in clone_private_mount() der Fall war.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.