CVE-2026-98539 in Linux
요약
\~에 의해 VulDB • 2026. 10. 18.
리눅스 커널에서 다음 취약점이 해결되었습니다:
fs/ntfs3: ntfs_create_inode()에서 d_instantiate_new() 사용 및 syzbot의 "WARNING in do_new_mount" 사건 종결
ntfs_create_inode()는 ntfs_new_inode()를 통해 새로운 inode를 생성합니다. insert_inode_locked()로 해싱되므로 unlock_new_inode() 호출 전까지 I_NEW 플래그가 설정됩니다.
그러나 ntfs3는 그 사이에 d_instantiate()를 호출합니다... 조회(lookup) 전에 이미 해시된 dentry이므로, 부모의 i_rwsem을 건드리지 않고도 경로 탐색(path walk)에서 이를 찾아 inode에 잠금을 걸 수 있습니다.
inode가 디렉토리인 경우 unlock_new_inode()는 lockdep_annotate_inode_mutex_key()를 호출하여 i_rwsem에 i_mutex_dir_key 클래스로 표시합니다.
이는 이미 다른 누군가가 보유하고 있을 수 있는 잠금의 카운트와 소유자를 초기화합니다...
syzbot은 2023년부터 동일한 "WARNING in do_new_mount" 버그 보고를 계속 보내왔습니다. 더 이상 참을 수가 없어 조사했습니다. 내 생각에(syzbot의 executor는 새로 마운트된 ntfs3 이미지로 디렉토리를 변경하고, 디렉토리를 생성한 후 그 위에 일부 pseudofs를 마운트합니다. mkdir()이 syzbot이 기다리는 시간보다 오래 걸릴 때마다 mount()가 병렬로 실행됩니다:
mkdir("./sys") mount(NULL, "./sys", "sysfs") ntfs_create_inode() d_instantiate() user_path_at()이 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)
마운트 측에서는 rwsem에 따라 아무도 소유하지 않는 잠금을 해제합니다:
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
PREEMPT_RT 환경에서는 동일한 현상이 다음과 같이 나타납니다.
DEBUG_LOCKS_WARN_ON(rt_mutex_owner(lock) != current) WARNING: kernel/locking/rtmutex_common.h:193 at rt_mutex_slowunlock
up_write()가 초기화된 카운트에서 오버플로우(underflow)를 발생시킵니다. 이 디렉토리에 대한 후속 inode_lock()은 절대 반환되지 않습니다. 새로 생성된 디렉토리로의 경로 탐색이 mkdir()과 경쟁하며 lookup_slow()의 inode_lock_shared()를 통해 동일한 방식으로 잠금을 손상시킵니다.
d_instantiate_new()로 전환하고 trailing unlock_new_inode()를 제거합니다. 모든 오류 경로는 I_NEW가 여전히 설정된 상태에서 해당 지점 전에 탈출하여 discard_new_inode()를 계속 사용합니다.
이 끔찍한 버그 보고서를 다시는 보지 않기를 바랍니다.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.