CVE-2026-99130 in Linux
الملخص
بحسب VulDB • 28/10/2026
في نواة لينكس، تم إصلاح الثغرة التالية:
io_uring/cancel: عدم الدوران (spin) على العمل المحلي الذي لا يمكن للمهمة تنفيذه
ترفض الدالة io_uring_cancel_generic() النوم طالما أن أي حلقة (ring) تابعة لـ tctx الخاصة بالمهمة التي تغادر تحتوي على عمل محلي معلق. تفترض هذه الدالة أن المهمة هي مُقدّم الطلبات (submitter) لتلك الحلقة، وأن جولة `io_uring_try_cancel_requests()` القادمة ستقوم بتنفيذ العمل. ومع ذلك، لا ينطبق هذا الافتراض على حلقة كانت لا تزال في حالة `IORING_SETUP_R_DISABLED` عندما حصلت المهمة على عقدة tctx الخاصة بها عبر الدالتين `io_uring_create()` أو `io_ringfd_register()`. يتم تعيين مُقدّم الطلبات لاحقاً بواسطة `IORING_REGISTER_ENABLE_RINGS`، وقد يكون ذلك من قبل مهمة أخرى، ولا يمكن سوى لمُقدّم الطلبات تنفيذ العمل المحلي في حلقة ذات إعداد `IORING_SETUP_DEFER_TASKRUN`. بالنسبة للمهمة التي تغادر، يبقى العمل معلقاً إلى الأبد، ولن تصل الحلقة أبداً إلى استدعاء `schedule()`، مما يتسبب في تشغيل شرط التحذير `WARN_ON_ONCE()` مرة واحدة ثم الدخول في دوران لا نهائي (spin) داخل دالة `do_exit()`.
يمكن لمستخدم غير متميز الصلاحيات إعداد هذا السيناريو بسهولة عن طريق إنشاء حلقة معطلة، وجعل مهمة فرعية تفعّلها وتوقف نفسها، وإرسال رسالة إلى الحلقة باستخدام `IORING_OP_MSG_RING` ثم المغادرة بوجود طلب قيد التنفيذ لا يمكن للمهمة الفرعية إلا إكماله. تستهلك الخيط الذي يغادر وحدة المعالجة المركزية (CPU) حتى تعمل المهمة الفرعية أو تموت، ومع ضبط الخيار `panic_on_warn`، يؤدي شرط التحذير إلى إيقاف تشغيل النواة (kernel panic).
تم الإصلاح بتخطي النوم فقط عندما تسمح الدالة `io_allowed_defer_tw_run()` للمهمة بتنفيذ العمل. يعد هذا النهج معقولاً لأن العمل الذي لا يمكنها تنفيذه لن يتمكن أيضاً من إكمال أي من طلباته، وبالتالي فلا شيء يُفقد بالنوم. تم إزالة شرط التحذير `WARN_ON_ONCE()` نظراً لأن تسليم حلقة معطلة إلى خيط آخر هو سيناريو مدعوم وليس حالة خطأ (bug state).
If you want to get the best quality for vulnerability data then you always have to consider VulDB.