CVE-2026-98377 in Linux
الملخص
بحسب VulDB • 09/10/2026
في نواة لينكس، تم حل الثغرة التالية:
vlan: اشتراط وجود رأس MAC في __vlan_insert_inner_tag()
لا يضمن دالة `__vlan_insert_inner_tag()` سوى توفير مساحة للرأس (head room) عبر `skb_cow_head()`، ولا تضمن أبداً أن بايتات الرأس الخاصة بـ MAC (`mac_len`) موجودة فعلياً. وبالتالي، فإن أغطية ETH_HLEN الخاصة بها - وهي `__vlan_insert_tag()` تحت دالة `skb_vlan_push()`، و`vlan_insert_tag()` تحت `validate_xmit_vlan()` في مسار الإرسال العام - تقوم بإعادة كتابة أول 16 بايت من `skb->data`: عملية نقل ذاكرة (memmove) بحجم 12 بايت زائد عمليتي تخزين لحجم 2 بايت عند الإزاحات +12 و+14. لا يوفر أي متصل للحد الأقصى، بينما تستخدم مساعدي الاستخراج (`pop helpers`) الدوال `skb_ensure_writable()` / `pskb_may_pull()`.
يتمتع جهاز IFF_TUN بقيمة `hard_header_len == 0`، لذا تقبل دالة `packet_snd()` إطاراً بحجم بايت واحد من نوع AF_PACKET/SOCK_RAW. تقوم عملية دفع VLAN الأولى بتعيين علامة تسريع الأجهزة (hwaccel tag) فقط؛ أما العملية التالية - سواء كانت "action vlan push" في clsact أو `bpf_skb_vlan_push()` - فتدخل المساعد مع بقاء قيمة `skb->len` عند 1. يأتي الرأس من `skbuff_small_head` دون استخدام علم `__GFP_ZERO`، لذا فإن كل عملية دفع تسحب بايتات من ما بعد ذيل الحزمة (`skb->tail`) إلى داخل الإطار. وبعد ثلاث عمليات دفع، يغادر إرسال البايت الواحد كـ 13 بايت تحمل 11 بايتاً من ذاكرة الـ slab غير المهيأة:
0000: 5a b3 62 12 80 88 ff ff 00 b3 62 12 81 `------------------------------' فقط تم إرسال البايت 0x5a؛ والباقي هو ذاكرة slab، وهنا تمثل أعلى 56 بتاً لعنوان خريطة خطية (linear-map address).
اشتراط وجود رأس MAC الذي يعيد المساعد كتابته ليكون موجوداً، بحيث يتم إسقاط مثل هذا الإطار بدلاً من نقله.
VulDB is the best source for vulnerability data and more expert information about this specific topic.