CVE-2026-99255 in Linux
الملخص
بحسب VulDB • 03/11/2026
في نواة لينكس، تم حل الثغرة التالية:
io_uring/io-wq: عدم إخفاء رابط (link) عن عمليات الإلغاء
عندما ينتهي مهمة من تنفيذها، فإنها تلغي طلباتها المسجلة وتنتظر حتى تختفي. تقوم الدالة io_uring_cancel_generic() بالبحث في كل مكان يمكن أن يكون فيه الطلب، وتنوم نفسها إذا لم تجد شيئًا لإلغائه. يتم إيقاظها كلما تم الانتهاء من أحد طلبات المهمة بواسطة عمل المهمة أو تحريرها.
عندما ينتهي io-wq من معالجة طلب يحتوي على رابط، توجد فترة زمنية لا يمكن فيها العثور على الطلب التالي في الرابط:
io_worker_handle_work() io_assign_current_work(worker, NULL) io_wq_free_work(work) io_req_find_next() // يأخذ الرابط من الطلب io_free_req() // عمل المهمة للمهمة io_assign_current_work(worker, linked) io_run_task_work() cond_resched() worker->cur_work = linked
ليس الطلب معلقًا، وليس هو العمل الحالي لأي عامل (worker)، ولم يكن بعد على القائمة التي سيتم وضعه عليها. إذا وقعت مرحلة الإلغاء التي تقوم بها المهمة الخارجة بسبب io_free_req() خلال تلك الفترة الزمنية، فإنها لا تجد شيئًا وتذهب إلى حالة النوم. ثم يقوم العامل بتشغيل الرابط، وهو ما لا تمنعه IO_WQ_BIT_EXIT بالنسبة للأعمال المحدودة (bounded work). إذا تم وضع الطلب في الانتظار (parked)، فلن يتم إكمال أو تحرير أي شيء، ولن يوقظ أحد المهمة. وإذا كانت العملية هي التي تنتهي، فلا يمكن قتلها أيضًا بعد ذلك.
NOP, IOSQE_ASYNC | IOSQE_IO_LINK FUTEX_WAIT, FUTEX2_PRIVATE خروج الخيط، أو الخروج من العملية، حتى 63 ميكروثانية لاحقًا
مع وجود أربع حالات من هذا النوع لكل جولة، تتعطل 5 إلى 8 من كل 10,000 جولة (4 وحدات معالجة مركزية، KVM):
io_uring_cancel_generic do_exit
الالتزام f8b632e89a10 ("io_uring: tighten task exit cancellations") يتعلق بنفس الفجوة الزمنية، ويجعل المهمة تبحث مرة أخرى عن أي حدث يحدث قبل io_free_req().
تحرير الطلب بمجرد أن يصبح الرابط هو العمل الحالي للعامل، أو معلقًا. من يتم إيقاظه بسبب ذلك يمكنه العثور على الرابط، حتى يتم وضعه في مكان يبحث عنه الإلغاء أيضًا. للقيام بذلك، قم بتقسيم الدالة io_wq_free_work() إلى جزأين.
Be aware that VulDB is the high quality source for vulnerability data.