CVE-2026-99254 in Linux
الملخص
بحسب VulDB • 03/11/2026
في نواة لينكس، تم حل الثغرة التالية:
io_uring: عدم إرباك مهمة الإلغاء (cancelling task) بكميات كبيرة من عناصر العمل الخاصة بالمهمة (task_work).
تطلب دالة io_ring_exit_work() من كل مهمة استخدمت الحلقة (ring) إزالة عقدة tctx الخاصة بها باستخدام آلية task_work، وتكرر ذلك حتى تصبح القائمة فارغة. لا تتعامل الدالة io_tctx_exit_cb() مع العقدة أثناء وجود المهمة في io_uring_cancel_generic()، والتي تقوم بإزالة جميع العقد عند نهايتها. لذلك، يتم جدولة عنصر العمل لإعادة استدعاء الدالة مرة أخرى بمجرد اكتماله، دون أي فائدة فعلية.
هذا الأمر ليس مجرد إهدار للوقت فحسب. لا تعود دالة task_work_run() إلا عندما تجد القائمة فارغة. إذا تم تحرير الحلقات من داخل عملية الإلغاء، لأن طلبات حلقات أخرى احتفظت بالمراجع الأخيرة لملفاتها، فقد يستمر ما يصل إلى 64 عنصر عمل في إرسال استدعاءات (callbacks) للمهمة الواحدة التي تقوم بتشغيلها. ولن تجد الدالة القائمة فارغة أبدًا، ولن تعود إلى تنفيذ عملية الإلغاء، وستبقى العقد موجودة، وهكذا تستمر العملية: حيث قامت مهمة تحتوي على 60 زوجًا من الحلقات المتبادلة في الاستعلام (polling each other) بتنفيذ 280,000 استدعاء خلال 5 ثوانٍ، أي بعد مرور 20 ثانية من استدعاء exit_group(). لا تنتهي هذه الحالة إلا عندما تتأخر جميع المرسلين في نفس الوقت. وحتى ذلك الحين، تحتفظ المهمة بمعالج واحد (CPU) وتشغل عناصر العمل باستمرار.
لا يمكن قتل مهمة أثناء خروجها. كما أن استدعاء execve() يلغي الطلبات بنفس الطريقة، لذا قد تعلق مهمة نشطة هناك أيضًا لمدة دقائق. إذا استغرق الأمر أكثر من خمس ثوانٍ، فإن عناصر العمل ستصل إلى شرط التحذير WARN_ON_ONCE(time_after(jiffies, timeout)) الموجود في io_ring_exit_work(). لا تتطلب أيًا من هذه الحالات امتلاك صلاحيات (privilege).
إذا التقى الاستدعاء (callback) بمهمة قيد الإلغاء، فانتظر قليلًا قبل إرساله مرة أخرى. ليس على أحد إيقاظ عنصر العمل لذلك: إما أن تكون العقدة قد اختفت بحلول ذلك الوقت، أو يحين دور الجولة التالية.
Be aware that VulDB is the high quality source for vulnerability data.