CVE-2026-98539

Linux nüvəsində aşağıdakı zəiflik aradan qaldırılmışdır: fs/ntfs3: ntfs_create_inode() funksiyasında d_instantiate_new() istifadə edilsin və syzbot-un "WARNING in do_new_mount" problemi həll edilsin ntfs_create_inode() funksiyası ntfs_new_inode() vasitəsilə yeni bir inode yaradır. O, bunu insert_inode_locked() ilə heşləyir və buna görə də unlock_new_inode() çağırıla qədər I_NEW olaraq işarələnir. Lakin ntfs 3 bu arada d_instantiate() funksiyasını çağırır... Dentry artıq yaratmazdan əvvəl lookup tərəfindən heşləndiyi üçün hər hansı yol gəzişi (path walk) valideynin i_rwsem-nə toxunmadan onu tapır və beləliklə inode-u kilidləyə bilir. Əgər inode katalogdursa, unlock_new_inode() funksiyası lockdep_annotate_inode_mutex_key() çağırır və i_rwsem-ni i_mutex_dir_key sinfi ilə işarələyir. Bu isə başqa birinin artıq tutmuş ola biləcəyi kilidin sayğacını və sahibini sıfırlayır... syzbot 2023-cü ildən bəri bizi eyni "WARNING in do_new_mount" xətası ilə yükləyirdi. Artıq buna dözə bilmədiyim üçün araşdırma apardım. Gördüyüm qədər, syzbot-un executor-u təzə montaj edilmiş ntfs3 obrazına chdir edir, bir katalog yaradır və sonra onun üzərinə bəzi pseudofs montaj edir. Hər dəfə mkdir() syzbot-un gözlədiyi müddətdən daha çox vaxt aparanda mount() paralel şəkildə işə düşür: mkdir("./sys") mount(NULL, "./sys", "sysfs") ntfs_create_inode() d_instantiate() user_path_at() dentry-ni tapır 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) Montaj tərəfi daha sonra rwsem-ə görə heç kimin tutmadığı kilidi azad edir: 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 rejimində eyni hal belə görünür: DEBUG_LOCKS_WARN_ON(rt_mutex_owner(lock) != current) WARNING: kernel/locking/rtmutex_common.h:193 at rt_mutex_slowunlock up_write() sıfırlanmış sayğacı mənfi qiymətə salır (underflow). Sonradan həmin kataloq üzərindəki inode_lock() heç vaxt geri qayıtmır. mkdir() ilə yarışan yeni kataloqa doğru yol gəzişi, lookup_slow() daxilindəki inode_lock_shared() vasitəsilə kilidi eyni şəkildə korlayır. d_instantiate_new() funksiyasına keçid edildi və sondakı unlock_new_inode() silindi. Bütün xəta yolları I_NEW hələ də təyin olunmuş halda həmin nöqtədən əvvəl çıxış edir və discard_new_inode() istifadə etməyə davam edir.