CVE-2026-97598: ipv4: fib: bound automatic table ID allocation
In the Linux kernel, the following vulnerability has been resolved:
ipv4: fib: bound automatic table ID allocation
fibemptytable() probes every table ID from 1 until it finds a free one. IPv4 tables are stored in a 256-bucket hash table, so a dense set of IDs makes each probe walk a growing hash chain while RTNL is held.
Automatic table assignment ("ip rule ... table 0") is an IPv4-only legacy path. Bound the automatically allocated ID to 4096 so the RTNL hold stays bounded, without changing lookups of explicitly specified table IDs.
This changes user-visible behavior. A table-0 rule previously received the lowest free ID in 1..RTTABLEMAX (0xFFFFFFFF). After this patch the search stops at 4096 and the rule add fails with ENOBUFS if that range is fully occupied. Explicit table IDs above 4096 remain usable.
The automatic path is unused in practice: it is IPv4-only, not documented by ip-rule, uncovered by kernel selftests, and both NetworkManager and systemd refuse table 0.
Affected Software
Event History
Frequently Asked Questions
Who is realistically exposed to this issue?
Exposure is limited to systems that use the IPv4 legacy automatic routing-table assignment path by adding an ip rule with table 0. The path is described as unused in practice, undocumented by ip-rule, and rejected by both NetworkManager and systemd.
What conditions are needed to trigger the resource-impacting behavior?
An attacker or local actor would need to cause automatic IPv4 table allocation while creating a dense set of occupied routing-table IDs. The pre-fix allocator probes IDs until it finds a free one while holding RTNL, and dense IDs increase the work performed.
Does the change affect explicitly configured routing-table IDs?
No. Explicit table IDs above 4096 remain usable, and their lookup behavior is unchanged. Only automatic assignment through table 0 is bounded.
What happens after the fix if automatic allocation cannot find a free ID?
Automatic allocation searches only IDs 1 through 4096. If all IDs in that range are occupied, adding the table-0 rule fails with ENOBUFS.