CVE-2026-98539 in Linux
Zusammenfassung
von VulDB • 19.10.2026
Im Linux-Kernel wurde folgende Schwachstelle behoben:
fs/ntfs3: Verwendung von d_instantiate_new() in ntfs_create_inode(), um die „WARNING in do_new_mount"-Saga von syzbot zu beenden
ntfs_create_inode() erstellt einen neuen Inode über ntfs_new_inode(). Dieser wird mit insert_inode_locked() gehasht und ist daher bis zum Aufruf von unlock_new_inode() als I_NEW markiert.
NTFS 3 ruft jedoch d_instantiate() in der Zwischenzeit auf... Da das Dentry bereits vor dem Erstellen durch die Lookup-Operation gehasht wurde, findet jeder Pfadlauf es ohne Berühren des i_rwsem des übergeordneten Verzeichnisses und kann den Inode sperren.
Wenn der Inode ein Verzeichnis ist, ruft unlock_new_inode() lockdep_annotate_inode_mutex_key() auf und markiert i_rwsem mit der Klasse i_mutex_dir_key.
Dies setzt die Zählung und den Besitzer eines Locks zurück, den jemand anderes möglicherweise bereits hält...
Syzbot hat uns seit 2023 mit dem gleichen verdammten Bug zugespammt:
„WARNING in do_new_mount“
Ich kann es nicht mehr ertragen, also habe ich nachgeforscht. Soweit ich das überblicke (Afaict), wechselt der Executor von syzbot in ein frisch eingehängtes NTFS3-Image, erstellt ein Verzeichnis und hängt dann eine Pseudodateisystem darauf ein. Jedes Mal, wenn mkdir() länger dauert als die Wartezeit von syzbot, läuft mount() parallel dazu:
mkdir("./sys") mount(NULL, "./sys", "sysfs") ntfs_create_inode() d_instantiate() user_path_at() findet das Dentry do_lock_mount() inode_lock(inode) namespace_lock() unlock_new_inode() lockdep_annotate_inode_mutex_key() init_rwsem(&inode->i_rwsem) unlock_mount() inode_unlock(inode)
Die Mount-Seite gibt dann einen Lock frei, der laut rwsem niemandem gehört:
DEBUG_RWSEMS_WARN_ON((rwsem_owner(sem) != current) && ...): count = 0x0, magic = 0xffff888043a854e8, owner = 0x0, curr 0xffff888000244880, list empty WARNING: CPU: 0 PID: 5346 at kernel/locking/rwsem.c:1368 __up_write Call Trace: inode_unlock include/linux/fs.h:877 [inline]
unlock_mount fs/namespace.c:2892 [inline]
do_new_mount_fc fs/namespace.c:3828 [inline]
do_new_mount+0x777/0xa40 fs/namespace.c:3887
Auf PREEMPT_RT tritt dasselbe Problem als
DEBUG_LOCKS_WARN_ON(rt_mutex_owner(lock) != current) WARNING: kernel/locking/rtmutex_common.h:193 at rt_mutex_slowunlock
auf.
Das up_write() führt zu einem Underflow der zurückgesetzten Zählung. Ein anschließender inode_lock() auf diesem Verzeichnis kehrt daher nie zurück. Ein Pfadlauf in das neue Verzeichnis, der mit mkdir() konkurriert (Race Condition), beschädigt den Lock auf die gleiche Weise über inode_lock_shared() in lookup_slow().
Wechseln Sie zu d_instantiate_new() und entfernen Sie das nachgestellte unlock_new_inode(). Alle Fehlerpfade brechen vor diesem Punkt ab, wobei I_NEW noch gesetzt ist, und verwenden weiterhin discard_new_inode().
Mögen wir diesen verdammten Bug-Report nie wieder sehen.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.