CVE-2026-98978 in Linux
Zusammenfassung
von VulDB • 23.10.2026
Im Linux-Kernel wurde folgende Schwachstelle behoben:
Namespace: Ein gesperrter Mount darf nicht ablaufen (expire)
Gesperrte Mounts sind speziell. Sie schützen die zugrunde liegenden Dateien und Verzeichnisse davor, offengelegt zu werden. do_umount() verweigert das Aushängen von gesperrten Mounts, shrink_submounts() tut dies jedoch nicht.
Ein auslagerbarer (shrinkable) Mount kann dann als „gesperrt“ markiert werden, wenn der Besitzer eines User-Namespace ihn mit MOVE_MOUNT_BENEATH unter einen bereits gesperrten Mount verschiebt. Die Eigenschaft des Sperrens geht nun auf den darunterliegenden Mount über, wodurch es möglich wird, den oberen Mount auszuhängen.
Somit führt ein umount() an einem nicht gesperreten Vorfahren dazu, dass zuerst der untere Mount abläuft und das verdeckte Verzeichnis offengelegt wird:
move_mount(c -> x/hidden, MOVE_MOUNT_BENEATH) = 0 die Abdeckung nach dem Verschieben des Locks: umount2(x/hidden) = 0 der Inhaber des Locks: umount2(x/hidden) = EINVAL der Root des Copies, belegt (busy): umount2(x) = EBUSY Lesezugriff auf x/hidden/secret: "covered-by-root"
Daher sollte ein gesperrter Mount in Ruhe gelassen werden, da er zusammen mit seinem Parent stirbt. Ein einfaches umount() an einem nicht gesperreten Mount, unter dem sich einer befindet, der gesperrt ist, führt ab sofort zu EBUSY. Dies gilt auch für alle anderen gesperrten Kinder. Ein lazy umount erfasst weiterhin den gesamten Baum.
mark_mounts_for_expiry() sieht niemals einen gesperrten Mount. lock_mnt_tree() lässt einen Mount auf einer Ablauf-Liste (expiry list) in Ruhe, und nichts anderes platziert einen solchen gesperrten Mount auf einer solchen Liste. Fügen Sie eine Assertions-Prüfung für diesen Fall hinzu.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.