CVE-2026-99073 in Linux
Summary
by MITRE • 10/23/2026
In the Linux kernel, the following vulnerability has been resolved:
ipv4: stop exception dump when nexthop group shrinks
Commit 4ce5dc9316de ("inet: switch inet_dump_fib() to RCU protection") allowed IPv4 FIB dumps to run concurrently with nexthop replacement.
fib_dump_info_fnhe() uses fib_info_num_path() as the loop bound, then fib_info_nhc() independently reloads nh->nh_grp. If RTM_NEWNEXTHOP replaces a group with fewer paths between those loads, fib_info_nhc() returns NULL and the dump dereferences it through nhc_flags.
Stop the walk when the indexed path is absent. Nexthop groups are dense, so the current snapshot has no later path.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 10/23/2026
The Linux kernel vulnerability identified in this advisory stems from a race condition within the IPv4 Forwarding Information Base (FIB) dump mechanism, specifically affecting how nexthop group information is accessed during concurrent operations. The root cause lies in the transition to Read-Copy-Update (RCU) protection for inet_dump_fib(), which was introduced by commit 4ce5dc9316de to allow IPv4 FIB dumps to run concurrently with nexthop replacement without holding heavy locks. While this change improves performance and reduces contention, it introduces a subtle timing window where data consistency is not strictly guaranteed across multiple independent reads within the same logical operation. The function fib_dump_info_fnhe() iterates over paths in a nexthop group using fib_info_num_path() as the loop bound to determine how many iterations are required. However, inside this loop, it calls fib_info_nhc(), which independently reloads the nh->nh_grp structure from memory. If an RTM_NEWNEXTHOP netlink message replaces or shrinks a nexthop group between the initial read of the path count and the subsequent access to individual paths, the index used in the current iteration may no longer correspond to a valid entry in the newly sized array.
This race condition results in fib_info_nhc() returning NULL because the indexed path is absent from the shrunken nexthop group. The critical failure occurs when the code attempts to dereference this NULL pointer through nhc_flags, leading to a kernel panic or denial of service for processes relying on FIB dump functionality. This scenario highlights a classic use-after-free or null-pointer dereference vulnerability arising from non-atomic access patterns in concurrent environments. Although RCU provides protection against memory reclamation issues by ensuring that freed objects remain accessible until all readers have completed their critical sections, it does not inherently protect against logical inconsistencies where the size of an array changes while iterators are still referencing indices based on a previous snapshot of its dimensions. The vulnerability is particularly relevant in high-throughput routing environments where nexthop groups are frequently updated to optimize traffic distribution or handle link failures.
From a classification perspective, this flaw aligns with CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization (Race Condition). Specifically, it involves a race between the iteration logic and structural modification of shared data structures without proper synchronization barriers that would ensure atomicity of the size check and element access. In terms of adversarial tactics, this vulnerability could be leveraged within the ATT&CK framework under T1498: Network Denial of Service or potentially as part of a broader exploitation chain leading to privilege escalation if an attacker can trigger repeated FIB dumps while manipulating nexthop configurations via netlink sockets. The impact is primarily availability-related for network management tools and routing daemons that depend on accurate fib dump outputs, but in severe cases, it can crash the entire kernel due to the null pointer dereference occurring in a context where stack traces are generated and system stability is compromised.
Mitigation strategies should focus on ensuring atomicity during the access of nexthop group elements relative to their size constraints. The primary fix involves modifying fib_dump_info_fnhe() to verify that each indexed path exists before attempting to dereference it, effectively stopping the walk when an absent index is detected. This approach acknowledges that nexthop groups are dense arrays and if a later path is missing in the current snapshot due to shrinking, no subsequent paths will exist either. Administrators should apply kernel patches that include this fix immediately after verification by their distribution vendors. Additionally, monitoring for unusual spikes in netlink traffic related to RTM_NEWNEXTHOP operations combined with frequent fib dumps may help detect potential exploitation attempts or stress conditions that trigger the race window. Long-term architectural improvements might involve using RCU-safe iteration mechanisms that hold a consistent snapshot of both size and elements simultaneously, thereby eliminating the possibility of accessing indices beyond the current valid range during concurrent modifications.