Instituto Nacional de ciberseguridad. Sección Incibe
Instituto Nacional de Ciberseguridad. Sección INCIBE-CERT

CVE-2026-23304

Gravedad:
Pendiente de análisis
Tipo:
No Disponible / Otro tipo
Fecha de publicación:
25/03/2026
Última modificación:
25/03/2026

Descripción

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipv6: fix NULL pointer deref in ip6_rt_get_dev_rcu()<br /> <br /> l3mdev_master_dev_rcu() can return NULL when the slave device is being<br /> un-slaved from a VRF. All other callers deal with this, but we lost<br /> the fallback to loopback in ip6_rt_pcpu_alloc() -&gt; ip6_rt_get_dev_rcu()<br /> with commit 4832c30d5458 ("net: ipv6: put host and anycast routes on<br /> device with address").<br /> <br /> KASAN: null-ptr-deref in range [0x0000000000000108-0x000000000000010f]<br /> RIP: 0010:ip6_rt_pcpu_alloc (net/ipv6/route.c:1418)<br /> Call Trace:<br /> ip6_pol_route (net/ipv6/route.c:2318)<br /> fib6_rule_lookup (net/ipv6/fib6_rules.c:115)<br /> ip6_route_output_flags (net/ipv6/route.c:2607)<br /> vrf_process_v6_outbound (drivers/net/vrf.c:437)<br /> <br /> I was tempted to rework the un-slaving code to clear the flag first<br /> and insert synchronize_rcu() before we remove the upper. But looks like<br /> the explicit fallback to loopback_dev is an established pattern.<br /> And I guess avoiding the synchronize_rcu() is nice, too.

Impacto