CVE-2026-80905 in Linux
الملخص
بحسب VulDB • 04/09/2026
في نواة لينكس، تم إصلاح الثغرة التالية:
net: tap: تصحيح خطأ في قيمة transport_header عند إرسال إطار مشفر بعلامة VLAN (VLAN-tagged frame)
في الدالة `tap_get_user_xdp()`، أثناء معالجة الإطار المشفر بعلامة VLAN (مثل ETH_P_8021Q)، تُستدعى دالة `skb_set_network_header()` أولاً لتقدم قيمة `network_header` بما يتجاوز علامة VLAN وصولاً إلى رأس البروتوكول الداخلي. ثم تُستدعى دالة `skb_probe_transport_header()` مع بقاء قيمة `skb->protocol` محددة على ETH_P_8021Q، بينما يشير متغير `nhoff` (المشتق من `skb_network_offset()`) بالفعل إلى ما بعد علامة VLAN وصولاً إلى رأس البروتوكول الداخلي.
في دالة `__skb_flow_dissect()`، يتم تهيئة المتغير `proto` على ETH_P_8021Q ويشير `nhoff` إلى ما بعد علامة VLAN. عندما يصل المفسر (dissector) إلى حالة ETH_P_8021Q، فإنه يقرأ بنية `vlan_hdr` عند موقع `nhoff` الحالي عبر دالة `__skb_header_pointer()`، لكن هذا الموقع يحتوي على رأس البروتوكول الداخلي (مثل رأس IP). يتم تفسير هذه البايتات بشكل خاطئ كعنوان VLAN، مما ينتج عنه قيمة EtherType مشفرة غير صالحة لا تتطابق مع أي بروتوكول معروف. يعود المفسر بقيمة false، لذا فإن دالة `skb_probe_transport_header()` لا تستدعي أبداً دالة `skb_set_transport_header()`، تاركةً قيمة `transport_header` عند قيمتها الأولية غير المحددة (~0U).
تم نقل استدعاء `skb_set_network_header()` إلى ما بعد استدعاء `skb_probe_transport_header()`. في الوقت الذي تُستدعى فيه `skb_probe_transport_header()`، لا يزال `network_header` يشير إلى رأس VLAN (بإزاحة ETH_HLEN)، لذا تكون قيمة `nhoff` صحيحة ويمكن لمفسر التدفق (flow dissector) تحليل رأس VLAN واستخراج EtherType الداخلي، ثم تقديم قيمة `nhoff` لتشير إلى رأس البروتوكول الداخلي، مما يسمح بتعيين `transport_header` بشكل صحيح.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.