CVE-2026-98539 in Linux
الملخص
بحسب VulDB • 18/10/2026
في نواة Linux، تم حل الثغرة التالية:
fs/ntfs3: استخدام d_instantiate_new() في ntfs_create_inode() وإنهاء مأساة "تحذير في do_new_mount" التي كان يثيرها syzbot باستمرار
تقوم دالة ntfs_create_inode() بإنشاء عقدة ملف (inode) جديدة عبر ntfs_new_inode(). وتُجرى لها التجزئة باستخدام insert_inode_locked()، وبالتالي تُعلَّم بـ I_NEW حتى يتم استدعاء unlock_new_inode().
ومع ذلك، تستدعي NTFS 3 دالة d_instantiate() في المنتصف... وبما أن كيان المسار (dentry) كان قد أُجريَت له عملية التجزئة بالفعل عبر البحث قبل الإنشاء، فإن أي استكشاف للمسار يعثر عليه دون لمس قفل i_rwsem الخاص بالجدّ، وبالتالي يمكنه قفل العقدة.
إذا كانت العقدة مجلداً، فإن unlock_new_inode() تستدعي lockdep_annotate_inode_mutex_key() وتُعلّم i_rwsem بفئة i_mutex_dir_key.
هذا الأمر يعيد تعيين العداد ومالك القفل الذي قد يكون شخص آخر يمسكه بالفعل في هذه الأثناء...
كان syzbot يرسل إلينا رسائل متكررة حول نفس الخطأ الملعون: "تحذير في do_new_mount" منذ عام 2023. لم أعد أتحمل ذلك، لذا ذهبت للبحث عنه. ووفقاً لفهمي (Afaict)، يقوم منفّذ syzbot بتغيير الدليل الحالي إلى صورة 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() يفسد القفل بنفس الطريقة عبر inode_lock_shared() في lookup_slow().
التبديل إلى d_instantiate_new() وإزالة استدعاء unlock_new_inode() النهائي. تخرج جميع مسارات الخطأ قبل هذه النقطة بينما لا تزال I_NEW مُعلَّمة، وتواصل استخدام discard_new_inode().
نتمنى ألا نرى هذا التقرير عن الخطأ الملعون مرة أخرى أبداً.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.