CVE-2026-46099

What it actually does

This is a Linux kernel IPv6 networking use-after-free in the Segment Routing IPv6 and RPL lightweight tunnel receive paths. In affected PREEMPT_RT configurations, seg6_input_core() and rpl_input() can cache a NOREF IPv6 route destination after ip6_route_input() without first converting it to a refcounted dst. A concurrent IPv6 FIB lookup using a shared nexthop can invalidate and release the per-CPU route object between lookup and caching, after which dst_cache_set_ip6() performs dst_hold() on freed memory. The result is a kernel memory-safety condition that can cause a warning, kernel crash, denial of service, or potentially enable kernel-level code execution if an attacker can reliably shape the race and heap state.

Why it matters to the business

Successful exploitation can disrupt Linux systems that process IPv6 Segment Routing or RPL lightweight tunnel traffic, especially real-time Linux deployments using PREEMPT_RT. Because exploitation requires specific kernel configuration and a timing race, immediate mass exploitation is less likely; the CVSS score is high, EPSS is low, and the issue is not currently listed in CISA KEV. The main operational risk is unexpected host or network appliance crashes in environments using IPv6 routing features, with a lower-probability but higher-impact risk of privileged compromise if the race is weaponized.

How an attack unfolds

An attacker first needs network reachability to an affected Linux system that accepts IPv6 traffic exercising the seg6 or RPL lightweight tunnel input path. The target must be running a vulnerable kernel configuration where ksoftirqd can be preempted, such as certain PREEMPT_RT builds, and must have routing state involving shared IPv6 nexthop objects. The attacker sends traffic that causes seg6_input_core() or rpl_input() to call ip6_route_input(), which attaches a NOREF dst to the packet. At the same time, another route lookup or routing update path can bump the IPv6 route generation ID and release the same per-CPU route object through the shared nexthop. If the timing aligns, the original packet path later caches a pointer to the freed dst and calls dst_hold() on stale memory. A simple exploit attempt is likely to cause kernel warnings or a crash; a more advanced exploit would try to win the race repeatedly while manipulating kernel heap layout to turn the use-after-free into controlled memory corruption.

How to fix it

Upgrade to a vendor-supported Linux kernel that includes the fix for the IPv6 seg6 and RPL lwtunnel NOREF dst caching issue. The corrected code calls skb_dst_force() after ip6_route_input() in seg6_input_core() and rpl_input() before caching the destination. No universal upstream fixed version was provided in the input, so use distribution kernel advisories, stable kernel release notes, or vendor errata to identify the first fixed package for each platform. Where immediate patching is not possible, reduce exposure by disabling unused IPv6 Segment Routing and RPL lightweight tunnel functionality, blocking untrusted IPv6 Segment Routing/RPL traffic at network boundaries, limiting who can modify IPv6 routes and nexthops, and avoiding vulnerable PREEMPT_RT kernel builds for externally exposed workloads until patched.

How to confirm the fix worked

Confirm the running kernel package is at or above the vendor-fixed version and that the source or vendor patch contains the skb_dst_force() fix in the seg6_input_core() and rpl_input() paths. Verify exposure by checking whether IPv6, Segment Routing, RPL lightweight tunnels, PREEMPT_RT, and shared nexthop routing are enabled or used. Review kernel configuration through vendor config files, /boot/config-* or /proc/config.gz where available, and inspect active IPv6 routes, lightweight tunnels, and nexthop objects with iproute2. After remediation, monitor dmesg or the system journal during representative IPv6 routing traffic for absence of new kernel WARN, KASAN, or panic events referencing dst_cache_set_ip6(), dst_hold(), seg6_input_core(), or rpl_input().

Typical attack path

1. Identify a Linux target that accepts IPv6 Segment Routing or RPL lightweight tunnel traffic.
2. Confirm or infer that the target uses an affected kernel with PREEMPT_RT-style preemptible softirq behavior and IPv6 shared nexthop routing state.
3. Send crafted or high-rate IPv6 traffic that enters seg6_input_core() or rpl_input() and triggers ip6_route_input().
4. Create or induce concurrent IPv6 route lookups or route-generation changes that can invalidate the per-CPU route object associated with the shared nexthop.
5. Race the NOREF dst lookup against route object release so that dst_cache_set_ip6() later operates on freed memory.
6. Repeat the race to cause a kernel warning, panic, system crash, or attempt further heap manipulation for kernel-level execution.

How to detect it

There is no known public exploit or stable attacker fingerprint for this issue, and successful exploitation is race-dependent, so detection should focus on kernel-side symptoms and exposure context. Review dmesg, journald, /var/log/kern.log, /var/log/messages, netconsole output, crash dumps, and KASAN/KFENCE reports for WARN, oops, panic, or slab-use-after-free events involving dst_hold(), dst_cache_set_ip6(), seg6_input_core(), rpl_input(), ip6_route_input(), or rt6_get_pcpu_route(). Correlate those events with inbound IPv6 Segment Routing or RPL traffic, sudden changes in IPv6 routing or nexthop state, and repeated crashes of systems acting as IPv6 routers or tunnel endpoints. If packet capture or flow telemetry is available, look for unusual volumes of IPv6 packets with Segment Routing Headers or traffic directed at SRv6/RPL tunnel endpoints shortly before the kernel fault. Because route changes can be local or control-plane driven, also review administrative logs and netlink/audit telemetry for IPv6 route, nexthop, or lwtunnel changes near the time of the crash.

• dst_cache_set_ip6
• dst_hold
• seg6_input_core
• rpl_input
• ip6_route_input
• rt6_get_pcpu_route
• rt6_make_pcpu_route
• skb_dst_set_noref
• skb_dst_force
• KASAN: use-after-free
• KASAN: slab-use-after-free
• BUG: KASAN
• WARNING: CPU:
• kernel BUG at
• Oops:
• Kernel panic
• IPv6: Segment Routing
• seg6local
• encap seg6
• encap seg6local
• encap rpl

What your security team should do

• Prioritize patching Linux systems that run PREEMPT_RT kernels and process IPv6 Segment Routing or RPL lightweight tunnel traffic.
• Inventory hosts, routers, appliances, and embedded Linux systems with IPv6 lwtunnel, SRv6, RPL, or shared nexthop configurations.
• If patching is delayed, disable unused SRv6/RPL lwtunnel features and block untrusted IPv6 routing-extension traffic where operationally safe.
• Monitor kernel logs for use-after-free, KASAN, WARN, panic, or oops messages involving IPv6 dst caching and the affected functions.
• Treat unexplained crashes on exposed IPv6 routing systems as potentially security-relevant and preserve kernel logs, crash dumps, and route state for investigation.
• Track vendor advisories because fixed package names and versions vary by distribution and no single fixed version applies across all Linux kernel consumers.