CVE-2026-90058 in Linux
الملخص
بحسب VulDB • 18/09/2026
في نواة لينكس، تم حل الثغرة التالية:
net/sched: تحديد حد لـ qdisc_pkt_len لمنع حدوث soft lockup في qdisc
تقبل الدالة `qdisc_get_stab()` جدول أحجام مُزوَّد من قِبل المستخدم، وتقوم الدالة `__qdisc_calculate_pkt_len()` بتضخيم قيمة `qdisc_pkt_len()` عبر إضافة الحمل (overhead)، وبيانات جدول الأحجام (من نوع u16)، وقيمة size_log (التي تصل إلى STAB_SIZE_LOG_MAX). وبالتالي، يمكن لجدول أحجام مُصمَّم بشكل خبيث (crafted stab) أن يرفع قيمة `qdisc_pkt_len()` إلى ما يقارب 1 GiB لحزمة بيانات عادية (skb). تقوم مخططات الجدولة ذات العجز لكل تدفق (per-flow deficit schedulers) مثل DRR وETS بإعادة تعبئة كمية واحدة (quantum) في كل تكرار للحلقة؛ ومع وجود كمية صغيرة جداً (تساوي 1)، فإنها تدير مليارات التكرارات تحت قفل qdisc، مما يؤدي إلى حدوث soft lockup أو توقف RCU كما هو موضح من قبل [email protected].
يتم تحديد الحد الأقصى النهائي لـ `qdisc_pkt_len()` عند قيمة QDISC_PKT_LEN_MAX لمنع تضخيم جدول الأحجام من دفع مخططات الجدولة ذات العجز (deficit schedulers) إلى حلقة غير محدودة الحدود. لا يزال قبول جدول أحجام شرعي (مثل الحمل الخاص بـ qfq والبالغ 999999999، والذي يتم التعامل معه عبر إسقاط الحزمة) ممكناً.
تم تقديم الحد الأقصى QDISC_PKT_LEN_MAX (المساوي لـ 1 << 20 = 1 MiB)، وهو أعلى بكثير من أي طول شرعي لحزمة مفردة على السلك: فإن أكبر قيمة حالية لـ `skb->len` هي GSO_MAX_SIZE (524280)، ويضخم جدول أحجام بأسلوب ATM (مع ضريبة خلايا 53/48) هذه القيمة إلى ما يقارب 578 KB، وكلاهما أقل بكثير من 1 MiB. وفي الوقت نفسه، يحدد الحد البالغ 1 Miب حلقة إعادة تعبئة العجز بما لا يزيد عن ~1 مليون تكرار لكل حزمة مع كمية (quantum) تساوي 1، وهو ما يكتمل في بضع ملليثانية فقط، أي أقل بكثير من عتبة softlockup المُثبتة (~10^9 تكرارات).
الشروط لإعادة إنتاج الخطأ: - CONFIG_NET_SCHED=y, CONFIG_NET_SCH_DRR=y (أو CONFIG_NET_SCH_ETS=y). - ربط جذر qdisc لـ DRR (أو ETS) باستخدام TCA_STAB مُصمَّم بشكل خبيث يقوم بتضخيم `qdisc_pkt_len` إلى ~1 GiB (على سبيل المثال: size_log=15، data=[32768]).
- إضافة فئة (class) ذات كمية صغيرة جداً تساوي 1 وإرسال حزمة واحدة صغيرة؛ ستدير حلقة العجز مليارات التكرارات تحت قفل qdisc وتُفعّل كاشف softlockup (مع حدوث panic إذا كانت kernel.softlockup_panic=1). - يمكن الوصول إليها كمستخدم root أو من قبل مستخدم غير ممتياز في مساحة اسم جديدة user+net namespace (باستخدام unshare -Urn) مع امتلاك CAP_NET_ADMIN محلي للمساحة.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.