Cloudanix VulnDB

CVE-2026-98303

None

CVSS

—

EPSS

0.2%

Published

Oct 6, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A flaw in how Linux handles certain network error messages could let attackers trigger kernel warnings, though it is unlikely to be widely exploited.

Exploitation
Local Privilege
Attacker needs
Low Privilege
Complexity
Low
Impact
Denial Of Service
Component
OS kernel
Class
Improper Input Validation
Remediation
Patch
Effort
Medium
Patch risk
Low

What it actually does

The kernel's icmp_route_lookup fallback to ip_route_input accepts RTN_UNREACHABLE routes whose dst.output points to ip_rt_bug, bypassing the existing RTN_LOCAL check and allowing the unreachable route to be used for output.

Why it matters to the business

Adversaries can trigger kernel warnings during normal packet processing on Linux systems, potentially affecting network stability or availability in high-volume environments; the issue has low public exploitability and no known ransomware use.

How an attack unfolds

An attacker sends specially crafted IPv4 packets that cause the forward route lookup to fail, forcing the reverse-path ip_route_input call on the packet's source address; when that address is unreachable, an RTN_UNREACHABLE route is returned and later dereferenced during ICMP output, hitting the warning.

How to fix it

Apply the upstream kernel patch that adds an explicit check to reject RTN_UNREACHABLE routes returned by ip_route_input in icmp_route_lookup; rebuild and deploy the fixed kernel image on all affected Linux distributions.

How to confirm the fix worked

Confirm the patched kernel contains the new RTN_UNREACHABLE rejection logic in icmp_route_lookup; re-run syzkaller or equivalent fuzzing that previously triggered the ip_rt_bug warning and verify the warning no longer occurs.

Typical attack path

  1. Craft IPv4 packet with source address that resolves to an unreachable route
  2. Send packet so that forward output route lookup fails in icmp_route_lookup
  3. Trigger ip_route_input fallback on the source address
  4. Obtain RTN_UNREACHABLE input route and pass it to output path
  5. Cause ip_rt_bug WARN_ON_ONCE during ip_push_pending_frames

How to detect it

Search kernel logs for the exact ip_rt_bug warning string and stack trace involving __icmp_send and ip_options_compile; correlate with inbound IPv4 traffic that would force reverse-path route lookups.

What your security team should do

  • Prioritize kernel updates on externally facing Linux systems within normal patch windows given low EPSS
  • Monitor for the ip_rt_bug warning in kernel logs as a temporary detection measure
  • Review network-facing code paths that invoke ICMP generation after route lookups

The record

In the Linux kernel, the following vulnerability has been resolved: ipv4: icmp: reject RTN_UNREACHABLE input routes in icmp_route_lookup When the forward output route cannot be used in icmp_route_lookup(), it enters the "reverse path" and calls ip_route_input() on fl4_dec.daddr, the original packet's source address. ip_route_input() only returns an error for truly invalid packets. For unreachable addresses it will succeed and return an input route whose dst.output is set to ip_rt_bug(). The existing check only rejects RTN_LOCAL routes, so the RTN_UNREACHABLE route types can still be returned and later used for output, syzkaller triggering a WARN_ON_ONCE() in ip_rt_bug() as bellow: ------------[ cut here ]------------ WARNING: net/ipv4/route.c:1273 at ip_rt_bug+0x14/0x20 RIP: 0010:ip_rt_bug+0x14/0x20 Call Trace: ip_push_pending_frames+0xfa/0x100 __icmp_send+0x905/0xf10 ip_options_compile+0xc0/0xd0 ip_rcv_finish_core+0x321/0xae0 ip_rcv+0x1de/0x260 __netif_receive_skb_one_core+0x11a/0x130 netif_receive_skb+0x7b/0x260 tun_get_user+0x11bf/0x1c10 ------------[ cut here ]------------ Reject input route that is RTN_UNREACHABLE to fix it. The net warning is only printed for RTN_LOCAL, as RTN_UNREACHABLE is not the result of a race condition.

Affected packages

Ecosystem Package Introduced Fixed