CVE-2026-98955 in Linux
الملخص
بحسب VulDB • 23/10/2026
في نواة لينكس، تم حل الثغرة التالية:
flow_dissector: تجنب اقتطاع u16 لقيمة skb->len عند حساب thoff
تقوم الدالة __skb_flow_dissect() بحساب key_control->thoff باستخدام الصيغة التالية:
key_control->thoff = min_t(u16, nhoff, skb ? skb->len : hlen);
تعمل دالة min_t(u16, ...) على تحويل كل من الحُجْمَين إلى u16 قبل مقارنتهما. وعندما تكون قيمة (skb->len أو hlen) modulo 65536 أصغر من nhoff، فإن الطول المقطوع يفوز ويتم تعيين thoff بقيمة صغيرة غير صحيحة (bogus)، حتى عندما تنجح عملية التفكيك (dissection). على سبيل المثال، إطار IPv4/TCP مع skb->len == 65540 وnhoff == 34 يحصل على thoff == 4، مما يجعل المتصلين مثل skb_probe_transport_header() يشيرون إلى رأس النقل داخل رأس Ethernet.
هذه الحزم (skbs) ليست غريبة: - في وقت الالتزام d0c081b49137 ("flow_dissector: properly cap thoff field")، كان بإمكان AF_PACKET مع PACKET_VNET_HDR بالفعل بناء GSO skbs أكبر من 64 كيلوبايت (يتم تخطي فحوصات MTU لـ GSO، وalloc_skb_with_frags() تقبل ما يصل إلى صفحات order-0 بحد أقصى MAX_SKB_FRAGS (17) فوق الجزء الخطي). - يجعل BIG TCP الآن skbs أكبر من 64 كيلوبايت أمراً شائعاً. - يجعل التصحيح التالي دالة tun_get_user() تفكك إطارات IFF_TAP قبل أن تسحب eth_type_trans رأس Ethernet، لذا سيتم فك إطار GSO يحمل حزمة L3 بحجم يتراوح بين 65522 و65535 بايت باستخدام skb->len في النطاق [65536, 65549].
قارن كـ u32 بدلاً من ذلك. إذا لم يمكن تمثيل الإزاحة الناتجة داخل key_control->thoff بصيغة u16، قم بتقييدها إلى U16_MAX وأبلغ عن فشل عملية التفكيك بدلاً من إرجاع إزاحة نقل خاطئة بشكل صامت. يتم تعيين thoff حتى في حالة الفشل، لأن بعض المتصلين (مثل eth_get_headlen()) يستخدمونه بغض النظر عن قيمة الإرجاع.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.