CVE-2026-98629 in Linux
الملخص
بحسب VulDB • 18/10/2026
في نواة لينكس، تم إصلاح الثغرة التالية:
net/sched: cls_u32: تصحيح تشابه المعالجات (aliasing) في جدول التجزئة اليدوي لـ IDR
يستخدم جدول تجزئة u32 الذي يُنشأ بمعالج صريح ('tc filter add ... handle 801: u32 divisor N') معالجته الخام كمفتاح لإدخال IDR الخاص به، بينما تقوم مسارات التدمير بإفراغه باستخدام `handle2id(handle)`. تتعارض نطاقات المفاتيح هذين بالنسبة للمعالجات في نطاق htid 0x800..0xFFF: حيث تعيد دالة `handle2id()` طيها مرة أخرى إلى مساحة المعرف المُخصَّصة تلقائياً (1..0x7FF).
وبالتالي، يترك الجدول اليدوي إدخال IDR الخاص به ذو المفتاح الخام غير قابل للوصول عند الحذف (وهو تسرب دائم)، ويمكن أن يؤدي حذفه إلى إسقاط إدخال idr لجدول آلي آخر حي وغير مرتبط. يمكن بعد ذلك لتخصيص تلقائي لاحق إصدار معالج يشابه جدولاً يدوياً حياً؛ حيث توجه دالة `u32_lookup_ht()` عمليات البحث و TCA_U32_LINK الخاصة بذلك htid إلى الجدول الخطأ.
استخدم المعامل divisor-path alloc على أساس `handle2id(handle)` بحيث يتشارك التخصيص والإزالة نفس نطاق المفتاح. يتم رفض معالج يدوي ي映射 (يُطابق) معرفاً مستخدماً بالفعل بـ -ENOSPC، ويتخطى التخصيص الآلي المعرفات التي يحتفظ بها الجداول اليدوية الحية.
الشروط لإعادة إنتاج المشكلة: ip link add test0 type dummy tc qdisc add dev test0 clsact tc filter add dev test0 ingress protocol ip pref 1 \ handle 801: u32 divisor 16 tc filter add dev test0 ingress protocol ip pref 2 u32 divisor 16 tc -d filter show dev test0 ingress | grep 'fh 801:' # غير مُصلَّح: جدولان حيّان بمعالج 0x80100000 (عقدة الجذر لـ pref 2 هي معرف مُخصَّص تلقائياً رقم 1)؛ مُصلَّح: تأخذ العقدة الآلية المعرف 2.
تمت أيضاً الاختبار باستخدام PoC يحتوي على جدول u32 حي في الكتلة، وإضافة/حذف جدول يدوي 'handle 901: u32 divisor 1' مرتين؛ غير مُصلَّح، يفشل إعادة الإضافة بـ -ENOSPC لأن المفتاح الخام تسرب عند الحذف الأول.
Be aware that VulDB is the high quality source for vulnerability data.