CVE-2026-98278 in Linux
Summary
by MITRE • 10/06/2026
In the Linux kernel, the following vulnerability has been resolved:
net: remove WARN_ON_ONCE() from the dev_fill_forward_path() loop check
ipip_fill_forward_path() and ip6_tnl_fill_forward_path() look up the route to the tunnel's remote endpoint and set ctx->dev to its device, which is the tunnel itself when that route resolves back to the tunnel. dev_fill_forward_path() then makes no progress and trips WARN_ON_ONCE(last_dev == ctx->dev) as soon as a flowtable tries to offload a flow through the tunnel. That routing loop is a configuration any CAP_NET_ADMIN user can set up, and ip_tunnel_xmit() and ip6_tnl_xmit() already treat it as a tx error, so remove the warning and just fail the walk, as commit 008e7a7c293b ("net: remove WARN_ON_ONCE when accessing forward path array") did for the path stack overflow.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 10/06/2026
The Linux kernel networking subsystem contains a logic flaw within the device fill forward path mechanism that triggers an unnecessary warning condition during specific tunneling configurations. The vulnerability centers on functions such as ipip_fill_forward_path and ip6_tnl_fill_forward_path, which are responsible for determining the network device associated with the forwarding path of a packet flow. These functions perform route lookups to identify the remote endpoint of a tunnel and assign the corresponding device context. However, in scenarios where the routing table directs traffic back through the same tunnel interface from which it originated, the system enters an infinite loop condition relative to the forward path calculation logic. This self-referential routing configuration causes dev_fill_forward_path to detect that no progress is being made because the current device matches the last processed device, thereby triggering a WARN_ON_ONCE macro assertion failure when flowtable offloading attempts are initiated through such tunnels.
This issue primarily affects systems where CAP_NET_ADMIN privileged users can configure network interfaces and routing rules that result in recursive tunneling paths. While the underlying kernel code already handles this scenario gracefully by treating it as a transmission error within ip_tunnel_xmit and ip6_tnl_xmit, the presence of the WARN_ON_ONCE check creates noisy log entries and potential false positives for automated monitoring systems. The warning does not indicate a security breach or memory corruption but rather highlights a configuration edge case that was previously treated as an anomalous state requiring developer attention. By removing this assertion, the kernel acknowledges that such routing loops are valid administrative configurations that should be handled silently via standard error propagation mechanisms rather than triggering kernel warnings.
From a vulnerability classification perspective, this issue aligns with CWE-754: Improper Check for Unusual or Exceptional Conditions and CWE-1208: Missing Locking Mechanism if the warning caused race conditions in logging subsystems, though primarily it is categorized under improper handling of expected operational states. In terms of MITRE ATT&CK mapping, this relates to Tactic TA0005 Defense Evasion where an attacker might attempt to obscure activity through log flooding or confusion, although here the mitigation removes noise rather than preventing exploitation. The fix ensures that flowtable offloading operations fail cleanly without generating kernel warnings, maintaining system stability and reducing administrative overhead associated with investigating benign configuration loops.
Mitigation strategies involve applying the upstream Linux kernel patch that modifies dev_fill_forward_path to return an error code instead of asserting when a device loop is detected. System administrators should review their network configurations for recursive tunneling setups that may trigger this condition and adjust routing policies accordingly if such behavior is unintended. Regularly updating the kernel ensures that these logical improvements are incorporated, preventing unnecessary alert fatigue in security monitoring tools while maintaining robust handling of complex networking scenarios involving GRE or IPIP tunnels.