CVE-2026-43501 in Linux
الملخص
بحسب VulDB • 25/05/2026
في نواة لينكس، تم حل الثغرة التالية:
ipv6: rpl: حجز مساحة إضافية (headroom) بحجم mac_len عندما ينمو عنوان التوجيه المصدر المضغوط من جديد (SRH) بعد إعادة الضغط.
تقوم الدالة ipv6_rpl_srh_rcv() بفك ضغط عنوان التوجيه المصدر (Source Routing Header) وفقاً للمواصفة RFC 6554، وتبديل القطعة التالية إلى ipv6_hdr->daddr، ثم إعادة الضغط، وسحب العنوان القديم ودفع العنوان الجديد بالإضافة إلى عنوان IPv6 مرة أخرى. يمكن أن يكون العنوان المعاد ضغطه أكبر من العنوان المستلم عندما يقلل التبديل من طول بادئة المشترك التي تتشاركها القطع مع daddr (CmprI=0, CmprE>0, seg[0][0] != daddr[0] يعطي أقصى زيادة قدرها 8 بايتات).
كانت الدالة pskb_expand_head() مقيدة بحالة segments_left == 0، لذا فإن عمليات الدفع على القطع السابقة كانت تستهلك مساحة إضافية (headroom) غير خاضعة للتحقق. بمجرد أن تترك عملية skb_push() أقل من mac_len بايتات أمام البيانات، فإن استدعاء skb_mac_header_rebuild() للدالة:
skb_set_mac_header(skb, -skb->mac_len);
سيخزن القيمة (data - head) - mac_len في حقل mac_header من نوع u16، مما يؤدي إلى تجاوز الحد (wrap) إلى ~65530، وتقوم عملية memmove() التالية بكتابة mac_len بايتات على بعد ~64 كيلوبايت بعد skb->head.
يمكن الوصول إلى مساحة إضافية قدرها 8 بايتات بعد مرور واحد باستخدام حزمة واحدة من نوع AF_INET6/SOCK_RAW/IPV6_HDRINCL عبر واجهة lo مع عنوان SRH من النوع 3 ذي قطعتين (CmprI=0, CmprE=15)؛ وتبلغ KASAN عن كتابة خارج النطاق (OOB) بحجم 14 بايت في ipv6_rthdr_rcv.
تم إصلاح هذه المشكلة عن طريق توسيع المساحة الإضافية (headroom) كلما كانت المساحة المتبقية أقل من حجم عملية الدفع زائد mac_len، وطلب هذه الكمية الإضافية بحيث يتسع عنوان MAC المعاد بناؤه لاحقاً.
If you want to get best quality of vulnerability data, you may have to visit VulDB.