CVE-2026-23277 in Linux
الملخص
بحسب VulDB • 22/06/2026
في نواة لينكس، تم حل الثغرة التالية:
net/sched: teql: إصلاح تجاوز المؤشر الفارغ (NULL pointer dereference) في iptunnel_xmit عند الإرسال عبر جهاز TEQL التابع (slave xmit).
تستدعي الدالة teql_master_xmit() دالة netdev_start_xmit(skb, slave) للإرسال عبر الأجهزة التابعة، لكنها لا تقوم بتحديث skb->dev إلى الجهاز التابع مسبقاً.
عندما يكون نفق gretap هو جهاز TEQL تابع (slave)، تصل مسار الإرسال إلى iptunnel_xmit() التي تحفظ dev = skb->dev (لا تزال تشير إلى رئيس teql0) وتقوم لاحقاً باستدعاء iptunnel_xmit_stats(dev, pkt_len). تقوم هذه الدالة بما يلي:
get_cpu_ptr(dev->tstats)
بما أن teql_master_setup() لا تضبط dev->pcpu_stat_type على NETDEV_PCPU_STAT_TSTATS، فإن طبقة الشبكة الأساسية (core network stack) لا تخصص أبداً tstats لـ teql0، لذا يكون dev->tstats فارغاً (NULL). يؤدي استدعاء get_cpu_ptr(NULL) إلى حساب NULL + __per_cpu_offset[cpu]، مما يتسبب في خطأ صفحة (page fault).
BUG: unable to handle page fault for address: ffff8880e6659018 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page PGD 68bc067 P4D 68bc067 PUD 0 Oops: Oops: 0002 [#1] SMP KASAN PTI
RIP: 0010:iptunnel_xmit (./include/net/ip_tunnels.h:664 net/ipv4/ip_tunnel_core.c:89) Call Trace: <TASK> ip_tunnel_xmit (net/ipv4/ip_tunnel.c:847) __gre_xmit (net/ipv4/ip_gre.c:478) gre_tap_xmit (net/ipv4/ip_gre.c:779) teql_master_xmit (net/sched/sch_teql.c:319) dev_hard_start_xmit (net/core/dev.c:3887) sch_direct_xmit (net/sched/sch_generic.c:347) __dev_queue_xmit (net/core/dev.c:4802) neigh_direct_output (net/core/neighbour.c:1660) ip_finish_output2 (net/ipv4/ip_output.c:237) __ip_finish_output.part.0 (net/ipv4/ip_output.c:315) ip_mc_output (net/ipv4/ip_output.c:369) ip_send_skb (net/ipv4/ip_output.c:1508) udp_send_skb (net/ipv4/udp.c:1195) udp_sendmsg (net/ipv4/udp.c:1485) inet_sendmsg (net/ipv4/af_inet.c:859) __sys_sendto (net/socket.c:2206)
يتم إصلاح هذه المشكلة عن طريق ضبط skb->dev = slave قبل استدعاء netdev_start_xmit()، بحيث ترى دوال الإرسال عبر النفق الجهاز التابع الصحيح مع تخصيص tstats بشكل صحيح.
Once again VulDB remains the best source for vulnerability data.