Answer in brief
CVE-2026-72421 records a Unknown severity vulnerability in ipv4: fib: Don't ignore error route in local/main tables.. 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.
Answer in brief
CVE-2026-72421 records a Unknown severity vulnerability in ipv4: fib: Don't ignore error route in local/main tables.. 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.
A CVSS score is not reported in the current record. 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 | >=f4530fa574df4d833506c53697ed1daa0d390bf4 <a29e95fbc51e8a1b932773fd0e259b2080881443 || >=f4530fa574df4d833506c53697ed1daa0d390bf4 <5ae18d87a45698e8244d0fcba64c658c35a7dd3d || >=f4530fa574df4d833506c53697ed1daa0d390bf4 <9127589aabdee588278e8d0d0bd3709a760a92c8 || >=f4530fa574df4d833506c53697ed1daa0d390bf4 <49eaf1403201357762d745a35882fb734107d763 || >=f4530fa574df4d833506c53697ed1daa0d390bf4 <fd25996f57a95d56bc568c89b4921edcf334b7d8 || >=f4530fa574df4d833506c53697ed1daa0d390bf4 <828fad4fd418bcdb9f5d66fec0d184c52a85ec31 || >=f4530fa574df4d833506c53697ed1daa0d390bf4 <a668fa160247d7bbe921548cb845f607b8b9305f || >=f4530fa574df4d833506c53697ed1daa0d390bf4 <b72f0db64205d9ce462038ba995d5d31eff32dc1 | a29e95fbc51e8a1b932773fd0e259b2080881443, 5ae18d87a45698e8244d0fcba64c658c35a7dd3d, 9127589aabdee588278e8d0d0bd3709a760a92c8, 49eaf1403201357762d745a35882fb734107d763, fd25996f57a95d56bc568c89b4921edcf334b7d8, 828fad4fd418bcdb9f5d66fec0d184c52a85ec31, a668fa160247d7bbe921548cb845f607b8b9305f, b72f0db64205d9ce462038ba995d5d31eff32dc1 |
| Linux/Linuxgeneric | 3.6 | Not reported |
Published upstream
Aug 15, 2026
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Aug 15, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Aug 15, 2026
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.
Quoted source text, attributed separately from HOL analysis.
A CVSS score is not reported in the current record. 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 | >=f4530fa574df4d833506c53697ed1daa0d390bf4 <a29e95fbc51e8a1b932773fd0e259b2080881443 || >=f4530fa574df4d833506c53697ed1daa0d390bf4 <5ae18d87a45698e8244d0fcba64c658c35a7dd3d || >=f4530fa574df4d833506c53697ed1daa0d390bf4 <9127589aabdee588278e8d0d0bd3709a760a92c8 || >=f4530fa574df4d833506c53697ed1daa0d390bf4 <49eaf1403201357762d745a35882fb734107d763 || >=f4530fa574df4d833506c53697ed1daa0d390bf4 <fd25996f57a95d56bc568c89b4921edcf334b7d8 || >=f4530fa574df4d833506c53697ed1daa0d390bf4 <828fad4fd418bcdb9f5d66fec0d184c52a85ec31 || >=f4530fa574df4d833506c53697ed1daa0d390bf4 <a668fa160247d7bbe921548cb845f607b8b9305f || >=f4530fa574df4d833506c53697ed1daa0d390bf4 <b72f0db64205d9ce462038ba995d5d31eff32dc1 | a29e95fbc51e8a1b932773fd0e259b2080881443, 5ae18d87a45698e8244d0fcba64c658c35a7dd3d, 9127589aabdee588278e8d0d0bd3709a760a92c8, 49eaf1403201357762d745a35882fb734107d763, fd25996f57a95d56bc568c89b4921edcf334b7d8, 828fad4fd418bcdb9f5d66fec0d184c52a85ec31, a668fa160247d7bbe921548cb845f607b8b9305f, b72f0db64205d9ce462038ba995d5d31eff32dc1 |
| Linux/Linuxgeneric | 3.6 | Not reported |
Published upstream
Aug 15, 2026
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Aug 15, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Aug 15, 2026
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.
Quoted source text, attributed separately from HOL analysis.