KernelScan.io

CRITICAL Introduced in 3.6

ipv4 FibLookup Bypass

CVE-2026-72421

CVSS 10.0 / 10.0 NVD

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:N

KernelScan AI3.3LOW

01

In the Linux kernel, the following vulnerability has been resolved: ipv4: fib: Don't ignore error route in local/main tables. When CONFIG_IP_MULTIPLE_TABLES is enabled but no rule is added, fib_lookup() performs route lookup directly on two tables. Since the first lookup does not properly bail out, the result of an error route in the merged local/main table could be overwritten by another route in the default table: # unshare -n # ip link set lo up # ip route add 192.168.0.0/24 dev lo table 253 # ip route add unreachable 192.168.0.0/24 # ip route get 192.168.0.1 192.168.0.1 dev lo table default uid 0 cache <local> Once a random rule is added, the error route is respected: # ip rule add table 0 # ip rule del table 0 # ip route get 192.168.0.1 RTNETLINK answers: No route to host Let's fix the inconsistent behaviour.

02

Engine v0.6.0

Risk summary

A logic error in the IPv4 FIB lookup path causes error routes (unreachable, blackhole, prohibit) in the local/main table to be silently ignored when no custom FIB rules are installed. Traffic that should be blocked by these error routes is instead routed via the default table, bypassing routing policy. This is reachable by unprivileged local users via network namespaces.

Affectedinclude/net/ip_fib.h (ipv4 fib)

Vulnerability analysis

When multiple routing tables are enabled but no custom policy rules are configured, the IPv4 routing lookup takes a fast path that checks the local/main table and then the default table sequentially. The fast path only stops on a successful match, so when the first table contains an error route (such as 'unreachable'), its result is discarded and overwritten by the second table's lookup, causing traffic that should be blocked to be routed instead. The fix changes the lookup to stop on any definitive result from the first table — not just success — so error routes are properly respected. This is reachable by any local user who can create a network namespace via user namespaces and configure routes within it.

03

BranchIntroducedFixed inPatch commit
5.103.65.10.261a29e95fbc51e
5.153.65.15.2125ae18d87a456
6.63.66.6.14549eaf1403201
6.123.66.12.97fd25996f57a9
7.13.67.1.5a668fa160247
6.183.66.18.40828fad4fd418
6.13.66.1.1789127589aabde
mainline3.67.2-rc1b72f0db64205