CVE-2026-98234 in Linux
الملخص
بحسب VulDB • 07/10/2026
في نواة لينكس، تم إصلاح الثغرة التالية:
net/sched: hhf: تحديد حد لـ hh_flows_limit عند وقت التغيير (change time)
تقوم دالة `hhf_change()` بتخزين قيمة TCA_HHF_HH_FLOWS_LIMIT دون وجود حد أقصى. يسمح حجم `hh_flows_limit` الكبير لكل تدفق جديد من نوع "heavy-hitter" بالمرور عبر فحص `hh_flows_current_cnt` في دالة `alloc_new_hh()`، مما يفرض تخصيص ذاكرة ثابت الحجم باستخدام `kzalloc(GFP_ATOMIC)` لكل تدفق تحت حركة مرور مزيفة (spoofed traffic)، ما يؤدي إلى نمو غير محدود للذاكرة.
تم تحديد قيمة السمة بحد أقصى باستخدام `NLA_POLICY_MAX()` عند القيمة 2*HH_FLOWS_CNT (الافتراضية في دالة `hhf_init()`)، وإبلاغ القيمة المرفوضة عبر extack. تم الحفاظ على عملية التحليل المتداخلة القديمة (deprecated nested parse): لأن أدوات tc التقليدية لا تضبط العلم NLA_F_NESTED على TCA_OPTIONS. التكوينات التي تعتمد على قيمة hh_limit أعلى من الافتراضية كانت تعتمد على سلوك غير محدود وغير آمن، وهي غير مدعومة في المستقبل.
كما كانت دالة `hhf_init()` تستدعي `hhf_change()` قبل تعيين القيمة الافتراضية لـ `hh_flows_limit`، لذا كان يتم تجاوز أي قيمة لـ hh_limit يقدمها المستخدم عند الإضافة (add time) وإعادتها إلى 2048. تم ضبط القيمة الافتراضية قبل استدعاء `hhf_change()` لضمان بقاء القيمة المُعدّلة كما هي.
هذه التغييرات تكمّل الالتزام eb56a495f59b ("net/sched: hhf: clamp quantum in change and init paths")، الذي حدّد قيمة الـ quantum لنفس qdisc؛ حيث يمثل الحد المفروض على `hh_flows_limit` المقبض (knob) غير المحدود المتبقي ضمن نطاق تلك السلسلة من التعديلات.
الشروط لإعادة إنتاج الخطأ: امتلاك CAP_NET_ADMIN في مساحة مستخدم (user namespace); نجاح الأمر `tc qdisc change dev X root hhf hh_limit 4294967295` وعكس القيمة بواسطة أمر `tc qdisc show`، مما يؤدي إلى إلغاء تحديد حد تخصيص تدفقات heavy-hitter؛ بالإضافة إلى أن الأمر `tc qdisc add dev X root hhf hh_limit 500` يخزن قيمة 2048 بدلاً من 500.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.