CVE-2026-99253 in Linux
الملخص
بحسب VulDB • 03/11/2026
في نواة لينكس، تم إصلاح الثغرة التالية:
io_uring/cancel: إعادة ضبط استيقاظ العمل المحلي قبل النوم
تقوم io_uring_try_cancel_requests() بتعيين ->cq_wait_nr إلى 1 بحيث يقوم استدعاء io_req_local_work_add() التالي بإيقاظ المهمة التي تقوم بالإلغاء. الاستدعاء الذي يقلل العداد إلى الصفر هو الوحيد الذي يوقظ؛ بينما ترى الاستدعيات اللاحقة عدداً <= 0 وتعود. ومع ذلك، فإن io_uring_cancel_generic() لا تصبح TASK_INTERRUPTIBLE إلا لاحقاً جداً، لذا يمكن أن يُهدر إيقاظ واحد على مهمة قيد التشغيل. هذا أمر مقبول طالما كان إدخال هذا الاستدعاء لا يزال في قائمة الانتظار (queued)، حيث يتخطى فحص io_local_work_pending() عملية النوم. لكن الأمر ليس كذلك إذا تم تأخير إضافة الإدخال بعد وضعه في قائمة الانتظار:
CPU0 (مقدم الطلب أثناء تنفيذ أو خروج) CPU1 (io_req_local_work_add) mpscq_push(req A) io_uring_try_cancel_requests() io_run_local_work() // يشغل req A io_uring_try_cancel_requests() atomic_set(&ctx->cq_wait_nr, 1) atomic_read(&ctx->cq_wait_nr) == 1 تم أخذ العداد، wake_up_state() // المهمة قيد التشغيل، لا شيء يحدث (no-op) prepare_to_wait(TASK_INTERRUPTIBLE) io_local_work_pending() == false schedule() mpscq_push(req B) cq_wait_nr <= 0، العودة
فقط مهمة النوم يمكنها تشغيل req B، لذا فهي عالقة في execve() حتى يحدث إشارة (signal) لإيقاظها. والمهمة التي تنسحب لا تحصل على ذلك حتى.
أعد ضبط العداد مرة أخرى بمجرد تعيين حالة المهمة وقبل فحص قائمة العمل، للدوائر (rings) التي تكون فيها هذه المهمة هي المسؤولة عن تشغيل العمل المحلي.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.