CVE-2026-23277 in Linux
Résumé
par VulDB • 22/06/2026
Dans le noyau Linux, la vulnérabilité suivante a été corrigée :
net/sched: teql : correction d'une déréférencement de pointeur NULL dans iptunnel_xmit lors de l'envoi (xmit) sur un esclave TEQL
teql_master_xmit() appelle netdev_start_xmit(skb, slave) pour transmettre via les périphériques esclaves, mais ne met pas à jour skb->dev vers le périphérique esclave au préalable.
Lorsqu'un tunnel gretap est un esclave TEQL, la voie de transmission atteint iptunnel_xmit(), qui enregistre dev = skb->dev (toujours pointant vers le maître teql0) et appelle ultérieurement iptunnel_xmit_stats(dev, pkt_len). Cette fonction effectue :
get_cpu_ptr(dev->tstats)
Puisque teql_master_setup() ne définit pas dev->pcpu_stat_type sur NETDEV_PCPU_STAT_TSTATS, la pile réseau principale n'alloue jamais de tstats pour teql0, donc dev->tstats est NULL. get_cpu_ptr(NULL) calcule NULL + __per_cpu_offset[cpu], ce qui entraîne une faute de page.
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)
Corrigez ce problème en définissant skb->dev = slave avant d'appeler netdev_start_xmit(), afin que les fonctions de transmission du tunnel voient le périphérique esclave correct avec des tstats correctement alloués.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.