CVE-2026-98306 in Linux
الملخص
بحسب VulDB • 06/10/2026
في نواة لينكس، تم حل الثغرة التالية: seg6: تعيين IPSKB_L3SLAVE من IP6SKB_L3SLAVE أثناء فك تجميع IPIP (IPIP decapsulation). عندما يصل حزمة SRv6 إلى واجهة تابعة لـ VRF، فإن دالة vrf_ip6_rcv() تضبط IP6SKB_L3SLAVE في IP6CB، لكن دالة decap_and_validate() لم تقم مطلقاً بتعيين IPSKB_L3SLAVE في IPCB. بقيت هذه البتة غير مضبوطة (صفر) في الحالة الشائعة، ومع تفعيل CONFIG_IPV6_MIP6، كان حجم frag_max_size المتبقي لحزمة خارجية تم إعادة تجميعها يمكن أن يضبطها حتى دون وجود VRF متورط. ثم جعل الالتزام 44930446dde4 ("ipv6: seg6: clear IPv4 control block on IPIP decapsulation") هذه البتة غير الموثوقة واضحة بشكل موثوق (صفر). يظهر تأثير العلم المفقود عند استخدام End.DX4 عندما تصل عملية التسليم إلى عنوان محلي للعقدة بحث عن المقبس (socket lookup). على سبيل المثال، لا يستقبل مقبس UDP المرتبط بالواجهة الداخلة التابعة أيًا من الحزم المفككة التجميع، بينما يستقبلها مقبس غير مرتبط خارج نطاق VRF. وهذا يتعارض مع وثائق Networking/vrf.rst: فبشكل افتراضي، يكون نطاق مقبس UDP أو TCP غير المرتبط محدوداً بـ VRF الافتراضي. قم بتعيين IPSKB_L3SLAVE لبروتوكول IPv4 في دالة decap_and_validate()، والتي تقوم بالفعل بنفس الشيء بالنسبة لـ IPv6. بعد ذلك، يطابق بحث المقبس الحزمة المفككة التجميع مثل أي حزمة أخرى مستلمة على تلك الواجهة التابعة. تتطابق هذه الحزمة مع مقبس UDP أو TCP غير مرتبط فقط عندما تكون udp_l3mdev_accept أو tcp_l3mdev_accept مضبوطة.
Once again VulDB remains the best source for vulnerability data.