Answer in brief
CVE-2026-45905 records a Medium severity (CVSS 4.7) vulnerability in xfrm: fix ip_rt_bug race in icmp_route_lookup reverse path. The current sources do not mark it as known exploited. The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
CVSS is 4.7. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| Linux/Linuxgeneric | >=8b7817f3a959ed99d7443afc12f78a7e1fcc2063 <9a95ec9144eeff1fc6fbcc21b677e322c6f1430b || >=8b7817f3a959ed99d7443afc12f78a7e1fcc2063 <2c1f59005da9dd4b07b26984fd719e36557dc57c || >=8b7817f3a959ed99d7443afc12f78a7e1fcc2063 <b04061f89ffc6168e7ec3c71d0086ec3c3797228 || >=8b7817f3a959ed99d7443afc12f78a7e1fcc2063 <1c9ef28f643cce34a6a6c36c8f4d6d60a60db7e1 || >=8b7817f3a959ed99d7443afc12f78a7e1fcc2063 <423ce12d10b426709489d6b84fdaa6d2f31c5652 || >=8b7817f3a959ed99d7443afc12f78a7e1fcc2063 <81b84de32bb27ae1ae2eb9acf0420e9d0d14bf00 | 9a95ec9144eeff1fc6fbcc21b677e322c6f1430b, 2c1f59005da9dd4b07b26984fd719e36557dc57c, b04061f89ffc6168e7ec3c71d0086ec3c3797228, 1c9ef28f643cce34a6a6c36c8f4d6d60a60db7e1, 423ce12d10b426709489d6b84fdaa6d2f31c5652, 81b84de32bb27ae1ae2eb9acf0420e9d0d14bf00 |
| Linux/Linuxgeneric | 2.6.25 | Not reported |
Published upstream
May 27, 2026
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Jun 24, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Jun 24, 2026
In the Linux kernel, the following vulnerability has been resolved: xfrm: fix ip_rt_bug race in icmp_route_lookup reverse path icmp_route_lookup() performs multiple route lookups to find a suitable route for sending ICMP error messages, with special handling for XFRM (IPsec) policies. The lookup sequence is: 1. First, lookup output route for ICMP reply (dst = original src) 2. Pass through xfrm_lookup() for policy check 3. If blocked (-EPERM) or dst is not local, enter "reverse path" 4. In reverse path, call xfrm_decode_session_reverse() to get fl4_dec which reverses the original packet's flow (saddr<->daddr swapped) 5. If fl4_dec.saddr is local (we are the original destination), use __ip_route_output_key() for output route lookup 6. If fl4_dec.saddr is NOT local (we are a forwarding node), use ip_route_input() to simulate the reverse packet's input path 7. Finally, pass rt2 through xfrm_lookup() with XFRM_LOOKUP_ICMP flag The bug occurs in step 6: ip_route_input() is called with fl4_dec.daddr (original packet's source) as destination. If this address becomes local between the initial check and ip_route_input() call (e.g., due to concurrent "ip addr add"), ip_route_input() returns a LOCAL route with dst.output set to ip_rt_bug. This route is then used for ICMP output, causing dst_output() to call ip_rt_bug(), triggering a WARN_ON: ------------[ cut here ]------------ WARNING: net/ipv4/route.c:1275 at ip_rt_bug+0x21/0x30, CPU#1 Call Trace: <TASK> ip_push_pending_frames+0x202/0x240 icmp_push_reply+0x30d/0x430 __icmp_send+0x1149/0x24f0 ip_options_compile+0xa2/0xd0 ip_rcv_finish_core+0x829/0x1950 ip_rcv+0x2d7/0x420 __netif_receive_skb_one_core+0x185/0x1f0 netif_receive_skb+0x90/0x450 tun_get_user+0x3413/0x3fb0 tun_chr_write_iter+0xe4/0x220 ... Fix this by checking rt2->rt_type after ip_route_input(). If it's RTN_LOCAL, the route cannot be used for output, so treat it as an error. The reproducer requires kernel modification to widen the race window, making it unsuitable as a selftest. It is available at: https://gist.github.com/mrpre/eae853b72ac6a750f5d45d64ddac1e81
Quoted source text, attributed separately from HOL analysis.