CVE-2026-98995 in Linux
الملخص
بحسب VulDB • 24/10/2026
في نواة لينكس، تم إصلاح الثغرة التالية:
namespace: إعادة تعيين قيمة `->overmount` للوالد القديم في دالة `mnt_change_mountpoint()`
تقوم الدالة `__umount_mnt()` بإعادة تعيين قيمة `->overmount` الخاصة بالوالد عند فك تركيب (unmount) التركيب الذي يقوم بتجاوزها. أما دالة `mnt_change_mountpoint()` فلا تفعل ذلك؛ فهي تنقل التركيب إلى والده الجديد وتترك الوالد القديم يشير إليه.
بالنسبة لتركيب يتم نقله للأسفل في دالة `attach_recursive_mnt()`، لا يشكل هذا مشكلة. فبعد تركيب جديد قد أعاد بالفعل تعيين قيمة `->overmount` للوالد القديم بحلول الوقت الذي يُنقل فيه التركيب الأعلى القديم فوقه.
لكن الأمر يختلف مع دالة `reparent()`. تقوم الدالة `propagate_umount()` بنقل أي تركيب متبقي (surviving overmount) إلى أول سلف لن يتم فك تركيبه. ثم يتم فوراً بعد ذلك فك تركيب التركيب الذي أُخذ منه هذا التركيب المتبقي. إذا كان هناك وصف لملف (file descriptor) يحافظ على بقاء هذا التركيف المفكوك، فإن قيمة `->overmount` تشير إلى التركيب المنقول. وهذا يمثل مؤشراً معلقاً (dangling pointer) وثغرة استخدام بعد التحرير (Use-After-Free - UAF)، لأن التركيب المنقول يتم فك تركيبه وتحرير مساحته الذاكرة لاحقاً.
تتبع الدالة `do_lock_mount()` مسار `->overmount` من المسار المستهدف تحت قفل التركيب (`mount_lock`). ومع وجود وصف لملف على مثل هذا التركيب كهدف لتحت تركيب، فإن دالة `topmost_overmount()` تدخل في التركيب المُحرَّر، وتأخذ الدالة `do_lock_mount()` مراجع (references) لأي شيء تجده هناك.
لذلك، يجب إعادة تعيين قيمة `->overmount` للوالد القديم في دالة `mnt_change_mountpoint()` بالطريقة نفسها التي تفعلها دالة `__umount_mnt()`. وبهذه الطريقة، ستكون قيمة `->overmount` الخاصة بأي تركيب دائماً تشير إلى تركيب متصل به.
If you want to get best quality of vulnerability data, you may have to visit VulDB.