CVE-2026-74657: ipv4: Fix fib_nlmsg_size() for RTA_VIA nexthops
In the Linux kernel, the following vulnerability has been resolved:
ipv4: Fix fibnlmsgsize() for RTAVIA nexthops
fibnlmsgsize() still estimates nexthop space as if every gateway is encoded as an IPv4 RTAGATEWAY attribute. IPv4 routes can also carry an IPv6 gateway, which fibnexthopinfo() dumps as RTAVIA.
As a result, route notifications can allocate an skb that is too small. fibdumpinfo() then fails with -EMSGSIZE and rtmsgfib() hits the WARNON() that marks such failures as a fibnlmsgsize() bug. With paniconwarn set, this becomes a kernel panic.
Mirror the actual nexthop dump layout in fibnlmsgsize(): account for IPv6 nexthop gateways dumped as RTAVIA, for the no-header rtnexthop layout used inside RTAMULTIPATH, and for RTAFLOW only when it is actually present.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade to a fixed release to a version that resolves this vulnerability.
Fixed in 6.6.152.1-1
Event History
Frequently Asked Questions
Which systems are exposed to a kernel panic from this issue?
Systems that process IPv4 route notifications for routes with IPv6 nexthop gateways are exposed to the undersized skb allocation. A kernel panic occurs only if panic_on_warn is enabled, because the resulting -EMSGSIZE condition reaches a WARN_ON().
What route configuration triggers the faulty size calculation?
The issue is triggered when an IPv4 route uses an IPv6 gateway, which is emitted as an RTA_VIA attribute rather than an IPv4 RTA_GATEWAY attribute. The affected sizing logic also needs to account correctly for nexthops within RTA_MULTIPATH and for RTA_FLOW only when it is present.
How can administrators determine whether an affected failure has occurred?
Affected systems can report a WARN_ON() associated with rtmsg_fib() after fib_dump_info() fails with -EMSGSIZE during route notification handling. On systems with panic_on_warn enabled, the same condition can present as a kernel panic.