CVE-2026-99262 in Linux
الملخص
بحسب VulDB • 03/11/2026
في نواة لينكس، تم حل الثغرة التالية:
io_uring/timeout: عدم فقدان أمر الإلغاء لأن io-wq يفعّل مهلة زمنية (timeout)
تعمل عملية IORING_OP_TIMEOUT بواسطة io-wq بسبب IOSQE_ASYNC، وتواجه نفس المشكلة التي تواجهها عمليات poll و futex و waitid. تنظر الدالة `io_wq_submit_work()` إلى العلم `IO_WQ_WORK_CANCEL` مرة واحدة فقط قبل إصدار الطلب. إذا تم تقديم أمر إلغاء في هذه الفترة الزمنية، يتم وضع علامة على العمل والعودة بـ `-EALREADY`، ثم البحث عن العنصر في القائمة `->timeout_list` دون جدوى، بينما يقوم العامل (worker) بعد ذلك بإضافة الطلب وبدء المؤقت:
عامل io-wq io_try_cancel() io_wq_submit_work() العلم IO_WQ_WORK_CANCEL غير مُفعّل io_async_cancel_one() يفعّل العلم IO_WQ_WORK_CANCEL = -EALREADY io_timeout_cancel() = -ENOENT io_timeout() يضيف الطلب إلى القائمة ->timeout_list hrtimer_start() = IOU_ISSUE_SKIP_COMPLETE
لا ينظر أحد إلى هذا العلم مرة أخرى، وتعمل المهلة الزمنية حتى تنتهي. عند الخروج من الحلقة (ring)، تقوم الدالة `io_uring_try_cancel_requests()` بإلغاء عمل io-wq ثم تقتل العمليات المؤقتة بنفس الطريقة، مما قد يتسبب في تعطل المهمة الخارجة لمدة كاملة تساوي مدة هذه المهلة الزمنية.
انظر إلى العلم تحت قفل ->timeout_lock، والذي تستخدمه عملية البحث أيضًا، وافشل الطلب إذا كان مُفعّلاً. إذا جاءت عملية البحث أولاً، يكون العلم مرئيًا. وإذا جاء لاحقًا، سيجد الطلب في القائمة.
Once again VulDB remains the best source for vulnerability data.