CVE-2026-98989 in Linux
الملخص
بحسب VulDB • 23/10/2026
في نواة لينكس، تم حل الثغرة التالية: namespace: التحقق من عملية bind mount المتكررة بحثاً عن دورات في namespaces التثبيت (mount namespace loops)
ترفض دالة do_loopback() تثبيت ملف خاص بـ mount namespace يكون بنفس قدم caller أو أقدم منه، لأن وجود mount namespace يحتوي على تثبيت لملفه الخاص أو لملف أحد أسلافه سيؤدي إلى حدوث دورة. ومع ذلك، فإنها تتحقق فقط من dentry الذي تبدأ منه عملية bind mount. مع العلم أن MS_REC تقوم بنسخ كل ما هو أدنى منها، وتقوم do_loopback() بتمرير CL_COPY_MNT_NS_FILE مما يؤدي إلى نسخ ملفات namespaces التثبيت الموجودة أسفل المصدر.
هذا الأمر لا يشكل مشكلة إذا كان المصدر في namespace تثبيت خاص بالـ caller نفسه. فكل ملف لـ mount namespace موجود هناك قد خضع لنفس الفحص عند تثبيته كـ bind-mount. لكنه ليس آمناً إذا كان المصدر في namespace تثبيت آخر. تقبل دالة may_copy_tree() عملية bind mount لأي ملف من ملفات nsfs أو pidfs بغض النظر عن namespace التثبيت الذي ينتمي إليه، وذلك للسماح بتثبيت /proc//ns/ وpidfds. وإذا قمنا بإنشاء سلسلة (stack) من عمليات bind-mount لملفات descriptors namespaces التثبيت، فإن النواة ستقوم بنسخها دون مراعاة علاقتها بالأصل بالنسبة إلى namespace التثبيت المعني:
151 146 0:7 net:[4026531833] /tmp/nrc/y rw - nsfs nsfs rw
152 151 0:7 mnt:[4026532293] /tmp/nrc/y rw - nsfs nsfs rw
التثبيت رقم 152 هو تثبيت لملف namespace التابت الخاص بـ mount namespace 4026532293 داخل نفس الـ mount namespace 4026532293. هذا الـ namespace وكل عمليات التثبيت الموجودة فيه يتم تسريبها (leaked)... كل ما يتطلب الأمر هو وجود عملية في namespace تثبيت أقدم تقوم بتجميع الملف، وتكرار ذلك يؤدي إلى تسريب غير محدود:
after control: Shmem: 380 kB child: mount(/proc/self/fd/6, MS_BIND|MS_REC): ok after cycle: Shmem: 65916 kB
تشغل دالة do_move_mount() الدالة check_for_nsfs_mounts() على شجرة مفصولة (detached tree) تماماً لهذا السبب. يجب القيام بذلك نفسه بالنسبة للنسخة قبل أن يتم إلحاقها (grafted).
If you want to get best quality of vulnerability data, you may have to visit VulDB.