CVE-2026-23304 in Linux
Summary
by MITRE • 03/25/2026
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.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 07/02/2026
The vulnerability CVE-2026-23304 represents a critical NULL pointer dereference in the Linux kernel's IPv6 routing subsystem that occurs during route processing when VRF (Virtual Routing and Forwarding) devices are being manipulated. This flaw exists in the ip6_rt_get_dev_rcu() function within the net/ipv6/route.c file, specifically at line 1418 where the kernel attempts to access a device pointer that may legitimately be NULL during the process of un-slaving a network interface from a VRF. The issue arises from a regression introduced by commit 4832c30d5458 which restructured how host and anycast routes are placed on devices with addresses, removing the previously established fallback mechanism to the loopback device.
The technical execution of this vulnerability occurs when the l3mdev_master_dev_rcu() function returns NULL because a slave device is in the process of being removed from its VRF master device, yet the ip6_rt_get_dev_rcu() function fails to handle this edge case properly. This situation typically manifests when VRF configurations are dynamically modified, such as during network reconfiguration or when interfaces are being torn down. The kernel's memory safety checker (KASAN) identifies the issue by detecting a null pointer dereference in the memory range 0x0000000000000108-0x000000000000010f, pointing directly to the problematic function execution path that leads through ip6_rt_pcpu_alloc() and ultimately to ip6_rt_get_dev_rcu(). The call trace demonstrates the execution flow from vrf_process_v6_outbound in the VRF driver through to the core routing functions, indicating that this vulnerability can be triggered during IPv6 packet processing when VRF configurations are active.
The operational impact of this vulnerability is severe as it can lead to kernel crashes and system instability when IPv6 routing is actively used in environments with dynamic VRF configurations. Attackers could potentially exploit this weakness by manipulating VRF device associations to trigger the NULL pointer dereference, causing denial of service conditions that might affect network connectivity or system availability. The vulnerability is particularly concerning in network infrastructure devices, routers, and switches that heavily utilize VRF functionality for network segmentation and isolation. According to CWE classification, this represents a CWE-476: NULL Pointer Dereference, which is a fundamental memory safety issue that can lead to system crashes or potentially privilege escalation in some contexts. The ATT&CK framework would categorize this under T1499.004: Endpoint Denial of Service, as it specifically targets the stability and availability of network endpoint services through kernel-level memory corruption.
Mitigation strategies for this vulnerability should focus on applying the appropriate kernel security patch that restores the fallback mechanism to loopback device when NULL pointers are encountered during VRF un-slaving operations. System administrators should prioritize updating their kernel versions to include the fix for this specific regression, particularly in environments where VRF functionality is actively used. Additionally, monitoring systems should be enhanced to detect unusual VRF configuration changes that might precede exploitation attempts. The fix implemented in the kernel maintains the established pattern of explicit fallback to loopback_dev, avoiding the need for complex synchronization mechanisms while ensuring robust error handling. Organizations should also consider implementing network segmentation strategies that reduce the frequency of dynamic VRF configuration changes, thereby minimizing exposure windows where this vulnerability could be exploited. Regular kernel security audits and vulnerability scanning should include verification of VRF-related routing functionality to prevent similar regressions from being introduced in future kernel modifications.