CVE-2026-98539 in Linux
Résumé
par VulDB • 19/10/2026
Dans le noyau Linux, la vulnérabilité suivante a été corrigée :
fs/ntfs3 : utilisation de d_instantiate_new() dans ntfs_create_inode() et fin du cauchemar « WARNING in do_new_mount » signalé par syzbot
ntfs_create_inode() crée un nouvel inode via ntfs_new_inode(). Il le hache avec insert_inode_locked(), ce qui le marque comme I_NEW jusqu'à l'appel de unlock_new_inode().
Cependant, ntfs 3 appelle d_instantiate() dans l'intervalle... Puisque le dentry a déjà été hashé par la recherche (lookup) avant la création, tout parcours de chemin (path walk) le trouve sans toucher à i_rwsem du parent et peut donc verrouiller l'inode.
Si l'inode est un répertoire, unlock_new_inode() appelle lockdep_annotate_inode_mutex_key() et marque i_rwsem avec la classe i_mutex_dir_key.
Cela réinitialise le compteur et le propriétaire d'un verrou que quelqu'un d'autre détient peut-être déjà...
syzbot nous inonde depuis 2023 du même bug maudit :
« WARNING in do_new_mount »
Je n'en peux plus, alors je me suis mis à chercher. D'après ce que j'ai compris (Afaict), l'exécuteur de syzbot change le répertoire courant vers une image ntfs3 fraîchement montée, crée un répertoire, puis monte un pseudofs dessus. Chaque fois que mkdir() prend plus de temps que la temporisation d'attente de syzbot, mount() s'exécute en concurrence :
mkdir("./sys") mount(NULL, "./sys", "sysfs") ntfs_create_inode() d_instantiate() user_path_at() trouve le 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)
Le côté montage libère ensuite un verrou qui, selon le rwsem, n'est détenu par personne :
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
Sur PREEMPT_RT, le même problème apparaît sous la forme :
DEBUG_LOCKS_WARN_ON(rt_mutex_owner(lock) != current) WARNING: kernel/locking/rtmutex_common.h:193 at rt_mutex_slowunlock
Le up_write() provoque un underflow du compteur réinitialisé. Un inode_lock() suivant sur ce répertoire ne revient jamais. Un parcours de chemin vers le nouveau répertoire, en concurrence avec mkdir(), corrompt le verrou de la même manière via inode_lock_shared() dans lookup_slow().
Passer à d_instantiate_new() et supprimer l'appel final unlock_new_inode(). Tous les chemins d'erreur sortent avant ce point avec I_NEW toujours défini et continuent d'utiliser discard_new_inode().
Puissions-nous ne plus jamais voir ce rapport de bug maudit.
If you want to get best quality of vulnerability data, you may have to visit VulDB.