CVE-2026-98984 in Linux
Zusammenfassung
von VulDB • 23.10.2026
Im Linux-Kernel wurde folgende Schwachstelle behoben:
dcache: Einen Mountpunkt nicht auf einem Dentry platzieren, der gerade entfernt wird
rmdir(), unlink() und rename() rufen dont_mount() für das Opfer (victim) auf und führen anschließend detach_mounts() mit dem gesperrten Inode des Opfers aus. do_lock_mount() übernimmt die Inode-Sperre des Mountpunkts und prüft cant_mount(), sodass nach detach_mounts() kein neuer Mountpunkt erscheinen kann.
attach_recursive_mnt() erstellt jedoch einen zweiten Mountpunkt für den Root des Quell-Mounts, damit die bereits am Zielort befindlichen Mounts darauf platziert werden können. Für diesen Vorgang wird kein Inode gesperrt, und d_set_mounted() lehnt nur ein Dentry ab, das entlinkt (unlinked) wurde. Zwischen detach_mounts() und d_delete() bleibt das Opfer weiterhin gehasht:
rmrace: b hat dont_mount() und detach_mounts() durchlaufen und schläft T2: move_mount(S, /tmp/plcant/x, BENEATH) = 0 errno 0 () T1: rmdir(/tmp/plcant/d/b) = 0 errno 0 109 107 0:61 /d/b//deleted /tmp/plcant/x rw,relatime - tmpfs tmpfs rw 108 109 0:63 / /tmp/plcant/x rw,relatime - tmpfs T rw
Ein Bind-Mount des Verzeichnisses, das entfernt wird, wird unter einen bestehenden Mount verschoben, während sich rmdir() zwischen den beiden Aufrufen befindet. Der Mount landet schließlich auf dem entfernten Verzeichnis und wird niemals mehr getrennt (detached).
Prüfen Sie auch in d_set_mounted() die Bedingung cant_mount(). dont_mount() setzt das Flag unter der d_lock-Sperre, bevor detach_mounts() ausgeführt wird; somit ist entweder der Mountpunkt zuerst gesetzt und detach_mounts() findet den Mount vor, oder das Flag wird erkannt und der Mount wird abgelehnt.
If you want to get best quality of vulnerability data, you may have to visit VulDB.