CVE-2026-74657 in Linux
Summary
by MITRE • 08/22/2026
In the Linux kernel, the following vulnerability has been resolved:
ipv4: Fix fib_nlmsg_size() for RTA_VIA nexthops
fib_nlmsg_size() still estimates nexthop space as if every gateway is encoded as an IPv4 RTA_GATEWAY attribute. IPv4 routes can also carry an IPv6 gateway, which fib_nexthop_info() dumps as RTA_VIA.
As a result, route notifications can allocate an skb that is too small. fib_dump_info() then fails with -EMSGSIZE and rtmsg_fib() hits the WARN_ON() that marks such failures as a fib_nlmsg_size() bug. With panic_on_warn set, this becomes a kernel panic.
Mirror the actual nexthop dump layout in fib_nlmsg_size(): account for IPv6 nexthop gateways dumped as RTA_VIA, for the no-header rtnexthop layout used inside RTA_MULTIPATH, and for RTA_FLOW only when it is actually present.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 08/22/2026
The Linux kernel networking subsystem contains a critical sizing miscalculation within the IPv4 forwarding information base implementation that leads to buffer overflow conditions during route notification generation. Specifically, the function fib_nlmsg_size() is responsible for calculating the required memory size for netlink messages used to communicate routing table changes to user space applications and other kernel components. This calculation determines how much sk_buff data area must be allocated before attempting to populate the message with actual routing information. The vulnerability arises because this estimation logic incorrectly assumes that all gateway addresses in IPv4 routes are encoded using the RTA_GATEWAY attribute, which corresponds strictly to 32-bit IPv4 addresses. However, modern Linux kernels support multipath routing and next-hop groups where a single route can reference multiple gateways, some of which may be IPv6 addresses even within an IPv4 context or when dealing with dual-stack configurations. When such routes are processed, the kernel attempts to dump these gateway details using the RTA_VIA attribute format rather than RTA_GATEWAY.
This discrepancy between the estimated size and the actual serialized data length results in the allocation of a socket buffer that is insufficiently sized for the content it must hold. As fib_dump_info() proceeds to populate this undersized buffer, it inevitably exceeds the allocated boundaries, triggering an -EMSGSIZE error code indicating message size mismatch. This failure condition propagates up the call stack and causes rtmsg_fib() to encounter a warning state marked by a WARN_ON macro, which flags the internal inconsistency in the sizing logic. While under normal circumstances this might merely result in a failed notification or a logged warning, the severity escalates significantly when kernel panic-on-warn settings are enabled, either globally via sysctl or locally through configuration options designed to catch programming errors early during development and testing phases. In such environments, the WARN_ON triggers an immediate kernel panic, effectively causing a denial of service by crashing the entire system whenever a route notification involving IPv6 gateways within an IPv4 context is attempted.
From a technical classification perspective, this flaw represents a classic buffer overflow scenario rooted in incorrect size estimation prior to memory allocation and data serialization. It aligns with CWE-131, which covers Incorrect Calculation of Buffer Size, as the root cause lies in failing to account for variable-length fields or alternative encoding formats when determining required storage space. Furthermore, because this vulnerability can be triggered by local users who have permission to modify routing tables via netlink sockets, it falls under CWE-787, Out-of-bounds Write, if the overflow were to corrupt adjacent memory structures rather than just failing safely with an error code in non-panic configurations. In terms of adversarial tactics, this issue relates to ATT&CK technique T1059, Command and Scripting Interpreter, specifically through netlink socket manipulation, although its primary impact here is availability disruption via system crash rather than direct command execution or privilege escalation. The vulnerability highlights the complexity of maintaining consistent data structures across different protocol versions within a unified kernel networking stack, where IPv4 routes must seamlessly handle IPv6 next-hop identifiers without proper size adjustments in the notification generation pipeline.
Mitigation strategies for this issue primarily involve applying the upstream kernel patch that corrects the fib_nlmsg_size() function to accurately mirror the actual nexthop dump layout. This fix ensures that space is reserved for RTA_VIA attributes when IPv6 gateways are present, accounts for the no-header rtnexthop structure used inside multipath routes, and correctly handles conditional inclusion of RTA_FLOW attributes only when they are actually utilized in the route entry. System administrators should ensure their Linux kernels are updated to versions that include this specific fix. For environments where immediate patching is not feasible due to stability concerns or long release cycles, restricting netlink socket access to trusted processes can reduce the attack surface by preventing unprivileged users from triggering route notification generation paths that exercise this code path. Additionally, disabling panic_on_warn in production systems may prevent a simple buffer sizing error from escalating into a full system crash, though this reduces visibility into other potential kernel bugs and is generally discouraged for security-hardened environments. Regular auditing of routing table configurations and monitoring for netlink-related errors in system logs can also aid in detecting attempts to exploit or trigger this condition before it leads to service disruption.