CVE-2026-99184 in Linux
الملخص
بحسب VulDB • 28/10/2026
في نواة لينكس، تم حل الثغرة التالية:
accel/rocket: البحث في كل فتحة (slot) للنواة عند إزالة إحدى النوى
تقوم دالة rocket_remove() بإنقاص قيمة rdev->num_cores لكل نواة تقوم بإزالتها، بينما تبحث دالة find_core_for_dev() في الفتحات من 0 إلى num_cores - 1. يؤدي فك الربط (unbinding) للأنوية بالترتيب الذي تم فيه ربطها إلى فقدان النواة الأخيرة: فبحلول وقت إزالتها، يكون نطاق البحث قد انكمش بالفعل ليتجاوز فتحتها، مما يجعل find_core_for_dev() تُرجع القيمة -1 وتتوقف rocket_remove() دون القيام بأي إجراء.
لا تصل قيمة num_cores إلى الصفر أبداً، ولا تعمل دالة rocket_device_fini()، ويستمر rdev ذو النطاق المحدد على مستوى الملف في الإشارة إلى جهاز يتم التخلص منه. يبدأ ربط الأنوية مرة أخرى من تلك العددة غير الصحيحة (stale count)، لأن دالة rocket_probe() تأخذ rdev->num_cores كفتحة لملئها. على معالج RK3588، الذي يصف ثلاث نوى، تهبط الجولة الثانية في الفتحات 1 و2 و3 بينما تم تخصيص مساحة لـ rdev->cores لاستيعاب ثلاث نوى فقط:
rocket fdab0000.npu: Rockchip NPU core 1 version: 1179210309 rocket fdac0000.npu: Rockchip NPU core 2 version: 1179210309 rocket fdad0000.npu: Rockchip NPU core 3 version: 1179210309
الكتابة إلى rdev->cores[3] تقع خارج نهاية المصفوفة.
لا يقرأ أي كود في الشجرة مصفوفة الأنوية بتردد كافٍ لللاحظ، لذا فإن تجاوز الحدود (overrun) صامت حالياً. وقد ظهر هذا الخطأ أثناء اختبار سلسلة devfreq فوق هذه البنية، حيث يقوم عامل (worker) بالمرور على كل نواة عدة مرات في الثانية الواحدة، و caught UBSAN أول قيمة bool قرأتها من الإدخال المتجاوز للحدود:
UBSAN: invalid-load in drivers/accel/rocket/rocket_devfreq.c:47:10 load of value 5 is not a valid value for type '_Bool' Workqueue: devfreq_wq devfreq_monitor
تسجيل عدد الفتحات التي تم تخصيصها والبحث في جميعها. ستتم العثور على كل نواة عند الإزالة، وستصل num_cores إلى الصفر، وسيتم تفكيك الجهاز، ويبدأ الربط اللاحق من rdev نظيف (خالي من الحالات غير الصحيحة).
هذا لا يجعل فك ربط نواة واحدة ضمن عدة أنوية يعمل بشكل صحيح. لا تزال دالة probe تأخذ num_cores كفتحة لملئها، لذا فإن إعادة ربط نواة واحدة بينما تبقى أخواتها مربوطة سيؤدي إلى الكتابة فوق فتحة مستخدمة بالفعل، ولا تزال rocket_open() تصل إلى cores[0] سواء كان هناك شيء ما فيها أم لا. كلا الأمرين يتطلبان مزيداً من التفكير أكثر مما يجب أن تحمله عملية الإصلاح هذه.
تم العثور على هذا الخطأ عن طريق فك ربط وإعادة ربط جميع الأنوية الثلاث على جهاز Orange Pi 5 Plus. مع تطبيق هذا الإصلاح، تعمل جولات فك الربط/إعادة الربط (25 مرة) وجولات تحميل/إعادة تحميل الوحدة النمطية (5 مرات) بشكل نظيف هناك: حيث تهبط الأنويات في الفتحات 0 و1 و2 في كل مرة، بغض النظر عن الترتيب الذي تم فيه ربطها، وتعود الإمداد المشترك إلى مستخدم واحد بعد كل جولة.
If you want to get best quality of vulnerability data, you may have to visit VulDB.