CVE-2026-98985 in Linux
الملخص
بحسب VulDB • 23/10/2026
في نواة لينكس، تم إصلاح الثغرة التالية:
namespace: التحقق من نقاط التثبيت (mounts) قبل قراءة آبائها في دالة pivot_root()
تقرأ الدالة `path_pivot_root()` آباء `new_root` وجذر المُستدعي (caller's root)، وتتحقق مما إذا كانت مشتركة (shared) قبل أن تتحقق مما إذا كان أي من نقاط التثبيت موجودًا ضمن مساحة الاسم الخاصة بالمُستدعي. يتم الاحتفاظ بـ `namespace_sem` فقط. وهذا أمر مقبول بالنسبة لنقطة تثبيت موجودة في مساحة اسم المُستدعي.
ولكن يمكن أن يكون `new_root` وصف ملف (file descriptor) لنقطة تثبيت تم فك تركيبها، ولا يبقى حياً إلا بفضل هذا الوصف للملف. إذا بقيت نقطة التثبيت متصلة بوالدها عند فك تركيبها، فلا يوجد ما يثبت الأب بالنسبة لها. يؤدي الإجراء النهائي `mntput()` الخاص بالأم إلى فصل الأطفال تحت قفل التثبيت (`mount_lock`) فقط ثم تحرير الأم لاحقًا:
pivot_root() close(fd), آخر مرجع على الوالد ------------ --------------------------------- ex_parent = new_mnt->mnt_parent mntput_no_expire_slowpath() __umount_mnt(new_mnt) cleanup_mnt() call_rcu() IS_MNT_SHARED(ex_parent)
BUG: KASAN: slab-use-after-free in path_pivot_root+0xf1a/0x1840 Read of size 4 at addr ffff8881047382f8 by task pivot_widen/157 path_pivot_root+0xf1a/0x1840 __x64_sys_pivot_root+0x165/0x190
ينطبق الأمر نفسه على جذر المُستدعي عبر `chroot()`. ينتهي كلا ناتجي الفحص بـ `EINVAL`، لذا فإن الخطأ لا يحدث إلا في عملية القراءة نفسها. إنه نفس الشيء الذي أصلحه الالتزام (commit) bb4609405752 ("statmount: read the parent of an unmounted mount under mount_lock") بالنسبة لـ `statmount()`.
تحقق من أن كلا نقطتي التثبيت موجودتان ضمن مساحة اسم المُستدعي قبل قراءة آبائهما. في كلتا الحالتين، تعود الدالة بـ `EINVAL`.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.