CVE-2026-45905

What it actually does

This is a Linux kernel race condition in the IPv4 ICMP error generation path when XFRM/IPsec policy handling causes icmp_route_lookup() to use the reverse-path route lookup logic. Under a narrow timing window, a route that was expected to represent a forwarding path can become a local route because an address is concurrently added to the system. The kernel may then attempt to use a route whose output function is ip_rt_bug for ICMP output, triggering a WARN_ON in net/ipv4/route.c. The primary impact is availability: a local privileged or semi-privileged actor able to influence networking state and packet delivery could cause kernel warnings and potentially destabilize systems depending on kernel panic-on-warn configuration. There is no indicated confidentiality or integrity impact.

Why it matters to the business

Affected Linux systems may experience service disruption if the race is triggered, especially on hosts with panic_on_warn enabled or where repeated kernel warnings lead to operational instability. The risk is most relevant to systems using advanced networking features such as IP forwarding, TUN/TAP interfaces, containers, network namespaces, routing changes, or XFRM/IPsec policy processing. Exploitation is assessed as low likelihood because it requires local access, privileges sufficient to manipulate networking behavior, and a difficult race condition; EPSS is very low and the vulnerability is not listed in CISA KEV. However, the operational consequence can be significant for routers, VPN gateways, container hosts, and network appliances where kernel availability is critical.

How an attack unfolds

An attacker first needs local access with the ability to generate crafted network traffic and influence network configuration or namespace state, such as adding an IP address at a precise moment. The attacker sends traffic that causes the kernel to generate an ICMP error and enter icmp_route_lookup(), including XFRM/IPsec-aware route handling. If the initial route lookup is blocked by policy or determines the destination is not local, the kernel enters the reverse-path logic and calls ip_route_input() to simulate the reverse packet input path. During the narrow race window, the attacker or cooperating process adds an IP address so that the destination used by ip_route_input() becomes local after the earlier locality check. The kernel receives an RTN_LOCAL route that is not valid for output, but vulnerable kernels fail to reject it. When the ICMP reply is emitted, dst_output() invokes ip_rt_bug(), causing a kernel WARN_ON. On systems configured to panic on warnings, this can crash the host; otherwise it may produce kernel warnings and degrade reliability.

How to fix it

Upgrade to a Linux kernel version that includes the xfrm/icmp_route_lookup fix, specifically the change that checks rt2->rt_type after ip_route_input() and rejects RTN_LOCAL routes for ICMP output. If vendor fixed package versions are available from the operating system distribution, apply the relevant kernel security update and reboot into the patched kernel. If no fixed package is yet available, monitor the Linux distribution vendor advisory and upstream stable kernel releases for this fix. As temporary risk reduction, restrict local administrative access, limit CAP_NET_ADMIN in containers and untrusted workloads, avoid granting unnecessary network namespace or TUN/TAP access, review panic_on_warn settings for availability-sensitive systems, and reduce exposure of XFRM/IPsec and forwarding configurations where not required.

How to confirm the fix worked

Confirm the running kernel includes the vendor fix by checking the installed and booted kernel version against the distribution advisory or upstream stable release notes. After patching, reboot and verify with uname -a that the active kernel is the fixed kernel, not only installed on disk. Validate that untrusted users and containers do not have CAP_NET_ADMIN or equivalent permissions unless required. For exposure assessment, identify systems with IP forwarding, XFRM/IPsec policies, network namespaces, TUN/TAP interfaces, or automation that frequently changes IP addresses. Kernel logs should no longer show WARN_ON traces involving ip_rt_bug during ICMP handling after remediation.

Typical attack path

1. Obtain local access to a vulnerable Linux system with sufficient privileges or capabilities to manipulate network configuration, namespaces, TUN/TAP traffic, or routing state.
2. Prepare traffic that causes the kernel to generate ICMP errors and traverse XFRM/IPsec-aware route lookup logic.
3. Coordinate a concurrent network address change, such as adding an IP address, to win the race between the route locality check and the ip_route_input() call.
4. Cause ip_route_input() to return an RTN_LOCAL route with dst.output set to ip_rt_bug in the reverse-path lookup.
5. Trigger ICMP output using the invalid output route.
6. Cause a kernel WARN_ON in ip_rt_bug, potentially resulting in a denial of service if the system panics on warnings or becomes unstable.

How to detect it

Review kernel logs and persistent journal data for WARN_ON traces from ip_rt_bug, especially call stacks containing ICMP output functions such as icmp_push_reply, __icmp_send, ip_push_pending_frames, and route handling in net/ipv4/route.c. Useful log sources include dmesg, journald kernel facility logs, /var/log/kern.log, /var/log/messages, crash dumps, kdump/vmcore data, and host EDR telemetry that captures kernel warnings or panics. Correlate events with local network configuration changes such as ip addr add, container or network namespace creation, TUN/TAP writes, IPsec/XFRM policy changes, or rapid address assignment on interfaces. Evidence of exploitation is not expected to include a remote payload or file artifact; the strongest indicators are the specific kernel warning and call trace around ICMP route output, particularly if repeated or temporally aligned with suspicious local network administration activity.

• WARNING: net/ipv4/route.c:1275 at ip_rt_bug
• ip_rt_bug+0x21/0x30
• dst_output
• ip_push_pending_frames
• icmp_push_reply
• __icmp_send
• icmp_route_lookup
• xfrm_lookup
• xfrm_decode_session_reverse
• ip_route_input
• ip_options_compile
• tun_get_user
• tun_chr_write_iter
• ------------[ cut here ]------------

What your security team should do

• Prioritize patching Linux systems that perform routing, VPN/IPsec, container networking, virtualization, or TUN/TAP-based packet processing.
• Verify whether panic_on_warn is enabled; if enabled, treat this as a higher availability risk and prioritize remediation for production systems.
• Restrict CAP_NET_ADMIN, TUN/TAP device access, and network namespace creation for untrusted users, containers, and workloads.
• Monitor distribution security advisories for the exact fixed kernel package and ensure systems reboot into the patched kernel after installation.
• Hunt kernel logs for ip_rt_bug WARN_ON traces and related ICMP/XFRM call stacks to identify possible triggering before remediation.
• Do not prioritize this above remotely exploitable or KEV-listed vulnerabilities unless the environment has high-value networking hosts with local multi-tenant or containerized workloads.