CVE-2026-23304
MediumCVSS 5.5Exploitation Probability (EPSS)
Low risk2th percentile - higher than 2% of all known CVEs
Summary
A NULL pointer dereference vulnerability was found in the Linux kernel's ip6_rt_get_dev_rcu() function. It occurs when a slave device is being un-slaved from a VRF, causing l3mdev_master_dev_rcu() to return NULL and leading to a system crash.
Risk Assessment
An attacker could exploit this vulnerability to cause a denial of service (DoS) by deliberately un-slaving network interfaces from VRF, resulting in kernel panic and system downtime.
Recommendation
Immediately update the Linux kernel to a version containing the fix that restores the fallback to the loopback interface when no master device is available.
Original NVD description (English source)
In the Linux kernel, the following vulnerability has been resolved: ipv6: fix NULL pointer deref in ip6_rt_get_dev_rcu() l3mdev_master_dev_rcu() can return NULL when the slave device is being un-slaved from a VRF. All other callers deal with this, but we lost the fallback to loopback in ip6_rt_pcpu_alloc() -> ip6_rt_get_dev_rcu() with commit 4832c30d5458 ("net: ipv6: put host and anycast routes on device with address"). KASAN: null-ptr-deref in range [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) I was tempted to rework the un-slaving code to clear the flag first and insert synchronize_rcu() before we remove the upper. But looks like the explicit fallback to loopback_dev is an established pattern. And I guess avoiding the synchronize_rcu() is nice, too.