UBUNTU-CVE-2026-98278: Medium severity ubuntu/linux-hwe-edge vulnerability
In the Linux kernel, the following vulnerability has been resolved: net: remove WARNONONCE() from the devfillforwardpath() loop check ipipfillforwardpath() and ip6tnlfillforwardpath() 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. devfillforwardpath() then makes no progress and trips WARNONONCE(lastdev == ctx->dev) as soon as a flowtable tries to offload a flow through the tunnel. That routing loop is a configuration any CAPNETADMIN user can set up, and iptunnelxmit() and ip6tnlxmit() already treat it as a tx error, so remove the warning and just fail the walk, as commit 008e7a7c293b ("net: remove WARNONONCE when accessing forward path array") did for the path stack overflow.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
ubuntu/linux-hwe-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-42.42~24.04.1 - Upgrade
Upgrade
ubuntu/linux-riscv-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-42.42.1~24.04.1 - Upgrade
Upgrade
ubuntu/linuxto a version that resolves this vulnerability.Fixed in 7.0.0-42.42 - Upgrade
Upgrade
ubuntu/linux-awsto a version that resolves this vulnerability.Fixed in 7.0.0-1016.17 - Upgrade
Upgrade
ubuntu/linux-gcpto a version that resolves this vulnerability.Fixed in 7.0.0-1016.18 - Upgrade
Upgrade
ubuntu/linux-ibmto a version that resolves this vulnerability.Fixed in 7.0.0-1017.17 - Upgrade
Upgrade
ubuntu/linux-oem-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1017.17 - Upgrade
Upgrade
ubuntu/linux-oracleto a version that resolves this vulnerability.Fixed in 7.0.0-1015.16 - Upgrade
Upgrade
ubuntu/linux-riscvto a version that resolves this vulnerability.Fixed in 7.0.0-42.42.1
Event History
Frequently Asked Questions
Who can trigger the warning condition?
A user with CAP_NET_ADMIN can configure a routing loop in which an IPIP or IPv6 tunnel's route to its remote endpoint resolves back to that same tunnel. The condition is reached when a flowtable attempts to offload traffic through that tunnel.
Does this affect ordinary tunnel traffic without a routing loop?
The described condition requires the tunnel remote-endpoint route to resolve back to the tunnel itself. The data does not indicate that normal tunnel configurations without this routing loop trigger the issue.
What happens when the problematic configuration is encountered?
Before the resolution, dev_fill_forward_path() makes no progress and triggers WARN_ON_ONCE(). The resolved behavior is to fail the forward-path walk; tunnel transmission paths already treat the routing loop as a transmit error.