CVE-2026-72215 in Linux
الملخص
بحسب VulDB • 16/08/2026
في نواة لينكس، تم إصلاح الثغرة التالية:
MIPS: DEC: ضمان وجود موقع مكدس (stack) بعرض 32 بت لـ o32 prom_printf()
في التكوينات ذات الـ 64 بت، يؤدي استدعاء أي نقاط دخول للبرنامج الثابت (firmware) من خيط نواة غير الخيط الأولي إلى وضع يكون فيه المكدس موضوعاً في مقطع ذاكرة XKPHYS ذي الـ 64 بت.
وبالتالي، لم يعد مؤشر المكدس قيمة بعرض 32 بت، وعندما يستخدم كود البرنامج الثابت ذو الـ 32 بت عمليات وحدة المنطق الحسابية (ALU) ذات الـ 32 بت للتحكم في مؤشر المكدس، تكون النتيجة المحسوبة غير صحيحة (في الواقع، في معمارية MIPS ذات الـ 64 بت، ستنتج تقريباً جميع عمليات ALU ذات الـ 32 بت نتائج غير متوقعة عند تنفيذها على بيانات بعرض 64 بت)، مما يؤدي إلى ضياع التحكم.
قد يحدث هذا عندما لا يكون قد تم تفعيل برنامج تشغيل وحدة الإخراج النهائية (console driver) في التكوين، وبالتالي يستمر استخدام وحدة الإخراج الأولية لفترة متأخرة من عملية التمهيد، أو مع تغيير قادم سيحول برنامج التشغيل zs لاستخدام جهاز منصة (platform device)، مما سيجعل تسليم التحكم لوحدة الإخراج يحدث فقط بعد بدء تشغيل خيوط نواة أخرى بالفعل، وستتعطل النواة عند:
pid_max: default: 32768 minimum: 301
أو في وقت لاحق قليلاً، ولكن دائماً قبل طباعة السطر التالي:
cblist_init_generic: Setting adjustable number of callback queues.
يبدو أن نقطة الدخول الوحيدة المتأثرة هي prom_printf(). ومن بين جميع نقاط الدخول الأخرى المرتبطة، يتم استدعاء rex_slot_address() وrex_gettcinfo() فقط من خيط نواة غير الخيط الأولي، وتحديداً kernel_init()، وهما دالتان ورقيتان (leaf functions) لا تتعاملان مع المكدس، وقد عملتا دون أي مشاكل منذ إضافة دعم الـ 64 بت للمنصة في عام 2002.
ولمعالجة هذه المشكلة، يتم ترتيب تبديل المكدس داخل الغلاف o32 المطلوب لـ prom_printf() فقط، عن طريق تزويد call_o32() بمؤشر إلى جزء من مساحة initdata، والتي تُوضع في مقطع التوافق ذي الـ 32 بت CKSEG0، مع ملاحظة أن prom_printf() يُستدعى فقط من معالج إخراج وحدة الإخراج وبالتالي يكون قفل وحدة الإحتفاظ بها مشغولاً (held)، مما يعني عدم الحاجة إلى جعل هذا الرمز قابلاً لإعادة الدخول (reentrant).
قد تُستدعى نقاط دخول البرنامج الثابت الأخرى بينما تكون المقاطعات مفعلة ولا يوجد أي قفل مستخدم، وقد تتطلب لذلك أن تكون call_o32() قابلة لإعادة الدخول. وهي لا تسبب أي مشكلة في هذه المرحلة و"إذا لم يكن هناك عطل فلا تصلح"، لذا نتركها دون تغيير.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.