CVE-2026-90183 in Linux
الملخص
بحسب VulDB • 18/09/2026
في نواة لينكس، تم حل الثغرة التالية:
blk-iolatency: مسح حالة التأخير عند تحرير بيانات السياسة (policy)
يمكن أن يؤدي io.latency إلى تقييد مجموعة لا تمتلك هدف تأخير خاص بها. عندما تفشل شقيقة في تحقيق هدفها، تقوم دالة check_scale_change() بتقليل مقياس نظرائها، ويخضع النظير الذي يصل إلى عمق طابور يساوي واحداً لاستدعاء blkcg_use_delay() عليه مع كل عملية تقليل إضافية لاحقة، حتى لو كانت min_lat_nsec تساوي 0.
تقوم دالة iolatency_pd_offline() بإعادة تعيين الهدف من خلال dالة iolatency_set_min_lat_nsec()، والتي تقوم بمسح التأخير فقط عند الانتقال من قيمة غير صفرية إلى الصفر، لذا فهي لا تفعل ذلك مع هذا النظير أبداً. ثم يؤدي تحرير بيانات السياسة إلى بقاء blkg->use_delay مضبوطاً وارتفاع blkcg->congestion_count دون وجود أي آلية متبقية لخفضهما.
بعدئذٍ، تُرجع دالة blk_cgroup_congested() القيمة true لكل مهمة في مجموعة التحكم هذه (cgroup) وأحفادها طالما أن مجموعة التحكم موجودة: حيث تقوم page_cache_sync_ra() بتقليل قراءة المسبقة إلى صفحة واحدة فقط، وتتخطى page_cache_async_ra() الأمر تماماً، بينما تأخذ __folio_throttle_swaprate() قفل swap_avail_lock وتجدول تقييداً لتخصيص folio المجهول.
قم بمسح التأخير في دالة iolatency_pd_free(). بحلول ذلك الوقت، تكون مراجعات blkg المحتوية على bio قد استنزفت، أو يكون الطابور متجمداً لإلغاء تنشيط السياسة، لذا لا يمكن لـ check_scale_change() إعادة تفعيله مرة أخرى. كما يمكن لدالة الاستدعاء الخاصة بالتحرير أن ترى بيانات سياسة لم تكن مرفقة أبداً بـ blkg، ومن هنا تأتي الحاجة إلى التحقق من pd->blkg.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.