CVE-2026-99070 in Linux
Summary
by MITRE • 10/23/2026
In the Linux kernel, the following vulnerability has been resolved:
ipv6: do not warn on route notification size race
fib6_info_hw_flags_set() sizes the skb with rt6_nlmsg_size() and later fills it with rt6_fill_node(). With nexthop compatibility mode enabled, a concurrent replacement can grow the group between these independent snapshots. rt6_fill_node() can then legitimately return -EMSGSIZE, so the warning does not prove a sizing bug.
Remove the warning. The existing error path still frees the skb and reports the error to listeners.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 10/24/2026
The Linux kernel vulnerability identified in this advisory relates to an improper handling of race conditions within the IPv6 forwarding information base implementation, specifically concerning route notification size calculations. This issue resides in the fib6_info_hw_flags_set function, which is responsible for preparing socket buffers for routing notifications. The core technical flaw arises from a timing discrepancy between two distinct operations: sizing the buffer using rt6_nlmsg_size and subsequently filling it with data via rt6_fill_node. Under normal circumstances, these steps are intended to ensure that the allocated memory space matches the expected size of the netlink message payload. However, when nexthop compatibility mode is enabled, a concurrent route replacement operation can dynamically alter the routing group structure between the initial sizing snapshot and the actual population phase. This concurrency allows the group configuration to expand in ways that were not anticipated by the static size calculation performed earlier in the sequence.
As a direct consequence of this race condition, rt6_fill_node may legitimately return an -EMSGSIZE error code because the pre-allocated buffer is insufficient for the now-larger data set. The original implementation interpreted this specific error outcome as evidence of a sizing bug and triggered a warning message to alert developers or administrators. This interpretation was technically incorrect because the size mismatch in this context is not due to a flaw in the allocation logic itself, but rather an expected side effect of concurrent modifications allowed by nexthop compatibility mode. The presence of these warnings creates noise in system logs and can lead to false positives during security auditing or stability monitoring, potentially masking more critical issues while distracting from normal operational behavior under high concurrency.
From a vulnerability classification perspective, this issue aligns with CWE-362, which covers concurrent execution using shared resources without proper synchronization. Although the immediate impact is limited to log noise and does not result in memory corruption, privilege escalation, or denial of service through resource exhaustion, it represents an improper handling of race conditions that could theoretically be exploited if similar patterns exist elsewhere in the kernel networking stack. The ATT&CK framework categorizes such behaviors under techniques related to defense evasion, specifically where system logs are manipulated or cluttered to obscure activity, although in this specific case, the primary concern is operational stability and log hygiene rather than malicious intent by an attacker.
The resolution involves removing the erroneous warning mechanism that triggers on -EMSGSIZE returns within this specific code path. By eliminating this false positive alert, the kernel maintains accurate logging practices while preserving the existing error handling logic. The current error path continues to function correctly by freeing the socket buffer and reporting the failure to listeners, ensuring that applications relying on these notifications are properly informed of the state change without generating spurious warnings. This fix underscores the importance of distinguishing between genuine implementation bugs and expected race conditions in highly concurrent environments like network stack processing.
To mitigate similar issues in other parts of the system or future developments, developers should ensure that size calculations for netlink messages account for potential dynamic changes during message construction when concurrency is possible. Implementing proper locking mechanisms to serialize access to routing group structures during notification preparation would prevent such race conditions entirely. Alternatively, re-evaluating the threshold for warning triggers can help reduce noise in production environments where transient state changes are common. System administrators should monitor kernel logs for any recurrence of similar patterns and ensure that their monitoring tools do not alert on known benign race condition outcomes until further patches or architectural improvements are deployed.