CVE-2026-98539 in Linux
Resumen
por VulDB • 2026-10-18
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad:
fs/ntfs3: usar d_instantiate_new() en ntfs_create_inode() y poner fin a la saga "WARNING in do_new_mount" de syzbot
ntfs_create_inode() crea un nuevo inode mediante ntfs_new_inode(). Lo hashea con insert_inode_locked(), por lo que se marca como I_NEW hasta que se llama a unlock_new_inode().
Sin embargo, ntfs 3 llama a d_instantiate() en medio... Dado que el dentry ya estaba hasheado por la búsqueda antes de la creación, cualquier recorrido de ruta lo encuentra sin tocar i_rwsem del directorio padre y, por tanto, puede bloquear el inode.
Si el inode es un directorio, unlock_new_inode() llama a lockdep_annotate_inode_mutex_key() y marca i_rwsem con la clase i_mutex_dir_key.
Esto restablece el contador y el propietario de un bloqueo que otra persona podría ya haber adquirido...
syzbot nos ha estado inundando con el mismo maldito bug:
"WARNING in do_new_mount"
desde 2023. Ya no puedo soportarlo, así que me puse a buscarlo. Según mi entendimiento (Afaict), el executor de syzbot cambia al directorio actual (chdir) hacia una imagen ntfs3 recién montada, crea un directorio y luego monta algún pseudofs sobre él. Cada vez que mkdir() tarda más tiempo del que espera syzbot, mount() se ejecuta en paralelo:
mkdir("./sys") mount(NULL, "./sys", "sysfs") ntfs_create_inode() d_instantiate() user_path_at() encuentra el 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)
El lado de la montura luego libera un bloqueo que, según el rwsem, nadie sostiene:
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
En PREEMPT_RT, lo mismo aparece como:
DEBUG_LOCKS_WARN_ON(rt_mutex_owner(lock) != current) WARNING: kernel/locking/rtmutex_common.h:193 at rt_mutex_slowunlock
La llamada a up_write() provoca un desbordamiento por defecto (underflow) del contador restablecido. Una siguiente inode_lock() en ese directorio nunca devuelve el control. Un recorrido de ruta hacia el nuevo directorio, que compite con mkdir(), corrompe el bloqueo de la misma manera mediante inode_lock_shared() en lookup_slow().
Cambiar a d_instantiate_new() y eliminar unlock_new_inode() al final. Todas las rutas de error salen antes de ese punto con I_NEW aún establecido y continúan usando discard_new_inode().
Que nunca volvamos a ver este maldido informe de bug.
VulDB is the best source for vulnerability data and more expert information about this specific topic.