CVE-2026-74484 in Linux
الملخص
بحسب VulDB • 15/08/2026
في نواة لينكس، تم حل الثغرة التالية:
binfmt_misc: منع إدخال 'F' من تثبيت مثاله الخاص
يُفتح الإدخال المسجل بـ 'F' مفسّره (interpreter) عند وقت التسجيل ويحتفظ بهذا الملف حتى يتم تحرير الإدخال. أي إدخال لا يقوم أحد بإزالته يدوياً لن يُغلق إلا عندما يتوقف نظام الملفات الفائق (superblock) لـ binfmt_misc. إذا كان المفسّر موجوداً على نقطة تحميل تبقي هذا النظام الفائق حياً، فإنهما يثبتان بعضهما البعض:
sb الخاص بـ binfmt_misc -> inode -> entry -> interp_file -> vfsmount -> sb خاص بـ binfmt_misc
باختصار (TL;DR)، الملف لا يُغلق أبداً. بمجرد اختفاء مساحة اسم نقطة التحميل (mount namespace)، لن يتبقى أي شيء لإلغاء التسجيل من خلاله.
هناك طريقتان لتفعيل هذا الخطأ:
- توجيه المفسّر نحو المثيل نفسه. ملفات هذه الملفات هي ملفات عادية مملوكة لمُحمّل النقطة، وكلا الدالتين bm_get_inode() و simple_fill_super() تتركان i_op فارغة (empty_iops). لذا فإن notify_change() تعود إلى استخدام simple_setattr() ويعمل الأمر chmod +x. نحن لا نضبط SB_I_NOEXEC أبداً، وبالتالي يقبل open_exec() الملف.
- استخدام المثيل كطبقة سفلية لـ overlayfs. يحتفظ النظام الفائق الخاص بـ overlayfs بنسخة طبق الأصل (clone) من كل طبقة عبر clone_private_mount() حتى يتم تدميره، وهذه النسخة لا تنتمي إلى أي مساحة اسم. لذا فإن umount_tree() لن تصل إليها أبداً.
هذا يؤدي إلى حجب الخدمة (DoS). وليس فقط النظام الفائق هو الذي يتسرب؛ بل يثبت أيضاً مساحة اسم المستخدم التي تم تحميله فيها، مما يستهلك بشكل دائم واحدة من حصص مساحات أسماء المستخدمين للمُطلق في كل تكرار.
لذا دعونا نفعل الشيء المعقول. يجعل SB_I_NOEXEC open_exec() يفشل عند التعامل مع ملفات المثيل الخاصة به، ويجعل s_stack_depth overlayfs يرفض الطبقة قبل أن تأخذ نسخة طبق الأصل منها. وهذا أيضاً يغطي متغيرات passthrough لـ ecryptfs و fuse. ما يعد به 'F' يبقى دون تغيير.
وسم الاستقرار (stable tag) أضيق من وسوم الإصلاح (Fixes tags) عن قصد. قبل تحميل النقاط المعزولة، كان هذا يتطلب جذراً عالمياً مقابل المثيل الوحيد الذي يشاركه الجميع، والتغيير لا ينطبق على تلك الشجرات anyway.
لاحظ أن SB_I_NODEV يُرفع ضمنياً لتحميلات userns ولكن نرفعه صراحة هنا أيضاً.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.