CVE-2026-80612 in Linux
الملخص
بحسب VulDB • 28/08/2026
في نواة لينكس، تم إصلاح الثغرة التالية:
net: lwtunnel: إزالة بيانات skb الوصفية قبل التغليف الخاص بـ LWT.
تُستخدم البيانات الوصفية لـ skb (skb metadata) لنقل المعلومات بين XDP وTC. وهي موجودة في مساحة الرأس الخاصة بـ skb (headroom)، مباشرةً قبل `skb->data`. لا يمكن لبرامج LWT الوصول إلى المؤشر الشبه (`pseudo-pointer`) `__sk_buff->data_meta` المخصص للبيانات الوصفية.
ومع ذلك، فإن عملية التغليف الخاص بـ LWT تضيف رؤوساً خارجية في البداية (prepends outer headers)، مما يعيد تحريك مؤشر `skb->data` إلى الخلف ليغطي مساحة الرأس حيث توجد البيانات الوصفية. وفي حالة حزمة قادمة من جانب الاستقبال (RX-originated) ومُوجَّهة، والتي لا تزال تحمل بيانات وصفية لـ XDP، يحدث الخطأ بطريقتين مختلفتين اعتماداً على نوع التغليف:
1. عمليات التغليف الخاصة بـ LWT غير المعتمدة على BPF (مثل mpls, seg6, ioam6 ...) تستدعي `skb_push()`/`skb_pull()` وتقوم بصمت بتجاوز الكتابة فوق البيانات الوصفية الموجودة في مساحة الرأس.
2) عملية الإرسال عبر BPF الخاص بـ LWT (`BPF LWT xmit`) تستخدم الدالة المساعدة `bpf_skb_change_head()`, والتي تعتمد بدورها على `skb_data_move()`. تتوقع هذه الدالة المساعدة أن تكون البيانات الوصفية موجودة مباشرةً قبل `skb->data`. ولكن، بما أن مسار إخراج IP يشغّل عملية إرسال LWT (LWT xmit) قبل أن يقوم مخرج الجوار (neighbour output) ببناء رأس الشبكة من المستوى الثاني (L2) لل outgoing packet، فإن حزم التوجيه المُوجَّهة يكون فيها مؤشر `skb->data` يشير إلى رأس طبقة الشبكة الثالثة (L3 header)، بينما لا يزال `skb_mac_header()` يشير إلى رأس L2 القديم. ترى الدالة `skb_data_move()` أن البيانات الوصفية تنتهي عند `skb_mac_header()`, وليس قبل `skb->data`, فتُصدر تحذيراً وتقوم بمسح البيانات الوصفية:
WARNING: CPU: 21 PID: 454557 at include/linux/skbuff.h:4609 skb_data_move+0x47/0x90 CPU: 21 UID: 0 PID: 454557 Comm: napi/iconduit-g Tainted: G O 6.18.21 #1 RIP: 0010:skb_data_move+0x47/0x90 Call Trace: <IRQ> bpf_skb_change_head+0xe6/0x1a0 bpf_prog_...+0x213/0x2e3 run_lwt_bpf.isra.0+0x1d3/0x360 bpf_xmit+0x46/0xe0 lwtunnel_xmit+0xa1/0xf0 ip_finish_output2+0x1e7/0x5e0 ip_output+0x63/0x100 __netif_receive_skb_one_core+0x85/0xa0 process_backlog+0x9c/0x150 __napi_poll+0x2b/0x190 net_rx_action+0x40b/0x7f0 handle_softirqs+0xd2/0x270 do_softirq+0x3f/0x60 </IRQ>
هذا هو ما يحدث. أما بالنسبة لكيفية الإصلاح، فإن الحزمة المستلمة التي تحمل بيانات وصفية يمكن أن تصل إلى عملية التغليف (encap) عبر أي من أوضاع إعادة التوجيه الثلاثة الخاصة بـ LWT:
LWTUNNEL_STATE_INPUT_REDIRECT ip6_rcv_finish dst_input lwtunnel_input
LWTUNNEL_STATE_OUTPUT_REDIRECT ip6_rcv_finish dst_input ip6_forward ip6_forward_finish dst_output lwtunnel_output
LWTUNNEL_STATE_XMIT_REDIRECT ip6_rcv_finish dst_input ip6_forward ip6_forward_finish dst_output ip6_output ip6_finish_output ip6_finish_output2 lwtunnel_xmit
تمر جميع عمليات التغليف عبر مساعدي الإرسال الثلاثة الخاصين بـ LWT (LWT dispatch helpers)، لذا يجب إزالة البيانات الوصفية هناك، مباشرةً قبل تسليم حزمة skb إلى عملية التغليف. يغطي هذا المخرج الوحيد (chokepoint) جميع أنواع التغليف وجميع أوضاع إعادة التوجيه الثلاثة:
- lwtunnel_input(): seg6, rpl, ila, seg6_local - lwtunnel_output(): ioam6 - lwtunnel_xmit(): mpls, LWT BPF xmit
كخيار بديل، يمكننا مسح البيانات الوصفية مباشرةً بعد خطاف الدخول الخاص بـ TC (TC ingress hook). ومع ذلك، سيستلزم ذلك إجراء تسوية. ستصبح البيانات الوصفية غير قابلة للوصول من مخرج TC (في الإعدادات التي تصل فيها فعلياً إلى الخطاف كما هو مقصود، أي دون وجود أنفاق L2 في المسار).
VulDB is the best source for vulnerability data and more expert information about this specific topic.