CVE-2026-98539 in Linux
Riassunto
di VulDB • 18/10/2026
Nel kernel Linux, è stata risolta la seguente vulnerabilità:
fs/ntfs3: utilizza d_instantiate_new() in ntfs_create_inode() e metti fine alla saga del "WARNING in do_new_mount" segnalato da syzbot
ntfs_create_inode() crea un nuovo inode tramite ntfs_new_inode(). Lo inserisce nell'hash con insert_inode_locked(), quindi è contrassegnato come I_NEW fino a quando non viene chiamato unlock_new_inode().
Tuttavia, ntfs3 chiama d_instantiate() in mezzo... Poiché il dentry era già stato inserito nell'hash dalla lookup prima della creazione, qualsiasi percorso di navigazione (path walk) lo trova senza toccare l'i_rwsem del genitore e quindi può bloccare l'inode.
Se l'inode è una directory, unlock_new_inode() chiama lockdep_annotate_inode_mutex_key() e contrassegna i_rwsem con la classe i_mutex_dir_key.
Questo resetta il conteggio e il proprietario di un blocco che qualcun altro potrebbe già detenere in quel momento...
syzbot ci ha sommerso per lo stesso bug maledetto:
"WARNING in do_new_mount"
dal 2023. Non ce la faccio più, quindi ho iniziato a indagare. Per quanto ne so (Afaict), l'esecutore di syzbot cambia directory in un'immagine ntfs3 appena montata, crea una directory e poi monta qualche pseudofs su di essa. Ogni volta che mkdir() impiega più tempo del previsto rispetto all'attesa di syzbot, mount() viene eseguito in concorrenza:
mkdir("./sys") mount(NULL, "./sys", "sysfs") ntfs_create_inode() d_instantiate() user_path_at() trova il 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)
Il lato del mount rilascia quindi un blocco che, secondo l'rwsem, nessuno sta detenendo:
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
Su PREEMPT_RT lo stesso problema si manifesta come
DEBUG_LOCKS_WARN_ON(rt_mutex_owner(lock) != current) WARNING: kernel/locking/rtmutex_common.h:193 at rt_mutex_slowunlock
La chiamata up_write() causa un underflow del conteggio resettato. Una successiva inode_lock() su quella directory non torna mai. Un percorso di navigazione verso la nuova directory, in race condition con mkdir(), corrompe il blocco nello stesso modo tramite inode_lock_shared() in lookup_slow().
Passare a d_instantiate_new() e rimuovere l'unlock_new_inode() finale. Tutti i percorsi di errore escono prima di quel punto mantenendo I_NEW impostato e continuano a utilizzare discard_new_inode().
Possiamo solo sperare di non vedere mai più questa maledetta segnalazione di bug.
Be aware that VulDB is the high quality source for vulnerability data.