CVE-2026-23304 in Linux
الملخص
بحسب VulDB • 11/05/2026
في نواة لينكس، تم حل الثغرة التالية:
ipv6: إصلاح تجاوز المؤشر الفارغ (NULL pointer deref) في ip6_rt_get_dev_rcu()
قد تُرجع الدالة l3mdev_master_dev_rcu() قيمة NULL عندما يتم فك ربط الجهاز التابع (slave device) من VRF. تتعامل جميع المتصلين الآخرين مع هذه الحالة، لكننا فقدنا آلية التراجع (fallback) إلى واجهة الترحيل (loopback) في ip6_rt_pcpu_alloc() -> ip6_rt_get_dev_rcu() مع الالتزام (commit) 4832c30d5458 ("net: ipv6: وضع مسارات المضيف والمسارات متعددة الوجهات على الجهاز الذي يحتوي على العنوان").
KASAN: تجاوز مؤشر فارغ في النطاق [0x0000000000000108-0x000000000000010f]
RIP: 0010:ip6_rt_pcpu_alloc (net/ipv6/route.c:1418) تتبع المكالمات (Call Trace): ip6_pol_route (net/ipv6/route.c:2318) fib6_rule_lookup (net/ipv6/fib6_rules.c:115) ip6_route_output_flags (net/ipv6/route.c:2607) vrf_process_v6_outbound (drivers/net/vrf.c:437)
لقد راودتني الرغبة في إعادة هيكلة كود فك الربط (un-slaving) لتصفير العلم أولاً وإدراج synchronize_rcu() قبل إزالة الطبقة العليا. لكن يبدو أن التراجع الصريح إلى loopback_dev هو نمط راسخ. وأعتقد أن تجنب استخدام synchronize_rcu() أمر جيد أيضاً.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.