CVE-2026-99033 in Linux
الملخص
بحسب VulDB • 23/10/2026
في نواة Linux، تم إصلاح الثغرة التالية:
net/packet: حماية عملية دفع رأس طبقة الوصلة (ll header) في packet_rcv_spkt()
تعيد دالة `packet_rcv_spkt()` بناء رأس طبقة الوصلة باستخدام الكود التالي:
`skb_push(skb, skb->data - skb_mac_header(skb));`
هذه العملية الطرحية تكون ذات معنى فقط عندما يكون للجهاز فعلياً رأس لطبقة الوصلة. كل من `packet_rcv()` و `tpacket_rcv()` تحيطان هذه العملية بـ `dev_has_header()`, وهو أيضاً الشرط (predicate) الذي يصف به التعليق الكتلي في بداية الملف عملية الاستعادة؛ بينما لا تفعل ذلك `packet_rcv_spkt()`. أدخلت الالتزام d549699048b4 ("net/packet: fix packet receive on L3 devices without visible hard header") المساعد البرمجي (helper) وقامت بتغيير موقعي الاتصال الاثنين، وبقي هذا الموقع متخلفاً عن الركب.
يمكن أن يترك الجهاز الذي لا يحتوي على رأس ll مرئي لـ `skb->mac_header` عند القيمة الحساسة 0xFFFF التي يقوم `__alloc_skb()` بتهيئتها إليها. يحدث ذلك مع حزم CAN (CAN skb): حيث تقوم `init_can_skb()` بتعيين `pkt_type` و `ip_summed` لكنها لا تعيد تهيئة الرؤوس، وقد أزالت الالتزام 9f10374bb024 ("can: remove private CAN skb headroom infrastructure") استدعاءات `skb_reset_*_header()` التي كانت موجودة سابقاً. وبالتالي يكون `skb_mac_header()` يساوي 0xFFFF، وتصبح الطول رقماً سالباً كبيراً، ويقوم `skb_push()` بالإبلاغ عن ذلك عبر `skb_under_panic()` -- من سياق softirq، مما يؤدي إلى توقف كامل للنظام (panic) حتى مع وجود `panic_on_oops=0`:
``` skbuff: skb_under_panic: text:ffffffff8bd21bc1 len:-65455 put:-65471 head:... data:... tail:0x50 end:0x180 dev:can0 kernel BUG at net/core/skbuff.c:214! RIP: 0010:skb_panic+0x50/0x60 Call Trace: <IRQ> skb_push+0x38/0x40 packet_rcv_spkt+0xe1/0x170 __netif_receive_skb_core.constprop.0+0x7e8/0xd30 ... Kernel panic - not syncing: Fatal exception in interrupt ```
نوع المقبس (socket) قابل للوصول: تقبل `packet_create()` نوع `SOCK_PACKET` إلى جانب `SOCK_RAW` و `SOCK_DGRAM` خلف نفس فحص الـ CAP_NET_RAW، ولا يمنع طول المقبس أو فحص القدرة الوصول من واجهة CAN.
تُعد استدعاءات `skb_reset_*_header()` المفقودة في `init_can_skb()` تراجعا برمجياً بحد ذاتها ويتم إصلاحها بشكل منفصل، لكن يجب ألا يؤدي مقبس packet إلى تحويل طبقة رابط لم تقم بتهيئة رأس mac الخاص بها إلى توقف للنواة (kernel panic). قم بحماية عملية الدفع بالطريقة التي تتبعها مسارات الاستقبال الأخرى.
تم الاختبار على الإصدار v7.3-rc5 تحت بيئة QEMU مع جهاز slcan متصل عبر pty، وهو مسار استقبال السائق: لا يمكن إعادة إنتاج المشكلة باستخدام vcan، لأن `can_send()` يعيد تهيئة الرؤوس أثناء الخروج. مقبس SOCK_PACKET واحد مرتبط بـ can0 وإطار بيانات واحد مكتوب في تأديب الخط (line discipline) يتسببان في توقف النواة غير المصححة مع المسار أعلاه؛ بينما الصورة نفسها مع هذا التصحيح لا تطبع أي رسالة panic وتقوم بإيقاف التشغيل بشكل طبيعي. كلا نسختي النواة هما من نفس الشجرة، مع التكوين الافتراضي بالإضافة إلى CONFIG_CAN_SLCAN=y، والفرق الوحيد هو هذه القطعة البرمجية (hunk).
If you want to get the best quality for vulnerability data then you always have to consider VulDB.