CVE-2026-89790 in Linux
Summary
by MITRE • 09/16/2026
In the Linux kernel, the following vulnerability has been resolved:
ipv6: avoid divide by zero in rt6_multipath_rebalance
rt6_multipath_rebalance() calculates the total eligible nexthop weight in one pass and programs upper bounds in a second pass. Since RTM_NEWROUTE is RTNL-free, a concurrent ignore_routes_with_linkdown update can make the first pass return zero while the second sees an eligible nexthop, causing rt6_upper_bound_set() to divide by zero.
UBSAN: division-overflow in net/ipv6/route.c:4845:17 Oops: divide error: 0000 [#1] SMP KASAN NOPTI
rt6_upper_bound_set() net/ipv6/route.c:4845 rt6_multipath_rebalance() fib6_add_rt2node() ip6_route_multipath_add() inet6_rtm_newroute()
Skip upper-bound calculation when the first pass reports a zero total. This respects the lock-free performance considerations here and solves insecure scenarios.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 09/16/2026
The vulnerability identified in the Linux kernel involves a critical divide-by-zero error within the IPv6 routing subsystem, specifically located in the rt6_multipath_rebalance function found in net/ipv6/route.c. This issue arises from a race condition inherent to lock-free data structures used for managing multipath routes. The function is responsible for rebalancing traffic across multiple next hops by calculating weights and setting upper bounds for packet distribution. During execution, the algorithm performs two distinct passes over the eligible nexthops: the first pass calculates the total weight of all valid paths, while the second pass uses this aggregate value to program upper bounds that dictate how traffic is distributed among those paths.
The root cause of the vulnerability lies in the asynchronous nature of route updates and the lock-free design intended to maintain high performance under concurrent access conditions. Specifically, when a new multipath route is added via RTM_NEWROUTE, which operates without holding the rtnl mutex, there exists a window where another process can simultaneously modify routing tables by ignoring routes associated with downed links through ignore_routes_with_linkdown updates. This concurrency allows for a scenario where the first pass of rt6_multipath_rebalance observes no eligible nexthops due to concurrent link state changes and consequently returns a total weight of zero. However, in the subsequent second pass, the system may encounter an eligible nexthop that was not accounted for or whose status changed during the brief interval between passes.
When this discrepancy occurs, the function rt6_upper_bound_set is invoked with a divisor derived from the previously calculated total weight, which remains at zero. This triggers a division-by-zero exception, leading to a kernel panic or crash as indicated by UBSAN reports and Oops messages referencing divide error operations in net/ipv6/route.c. The stack trace confirms that this execution path originates from ip6_route_multipath_add called during inet6_rtm_newroute processing, highlighting the direct impact on route manipulation commands issued by userspace applications or network management tools.
From a security perspective, this vulnerability is classified under CWE-369 which denotes divide-by-zero errors, and it maps to ATT&CK technique T1498 Network Denial of Service due to its potential to cause system instability through kernel crashes. The operational impact includes the denial of service for the affected host or network node, as a single crafted route addition command can crash the entire operating system if executed during specific timing windows involving concurrent link state changes. This represents a significant risk in environments where dynamic routing protocols are active and interface states fluctuate frequently, such as in cloud infrastructure or complex enterprise networks relying on Linux-based routers.
The resolution implemented by the kernel maintainers addresses this flaw by introducing a conditional check within rt6_multipath_rebalance to skip the upper-bound calculation if the first pass determines that the total eligible nexthop weight is zero. This simple yet effective mitigation preserves the lock-free performance characteristics of the routing subsystem while eliminating the possibility of division-by-zero errors in these race conditions. By ensuring that no arithmetic operation proceeds with a null divisor, the kernel maintains stability even under heavy concurrent modification scenarios.
To mitigate this vulnerability, system administrators should ensure that their Linux kernels are updated to versions containing this specific patch for net/ipv6/route.c. For systems where immediate patching is not feasible, monitoring network interface states and minimizing rapid changes in routing configurations can reduce the likelihood of triggering the race condition. Additionally, deploying intrusion detection systems capable of identifying anomalous route manipulation patterns may provide an additional layer of defense against exploitation attempts aimed at destabilizing critical infrastructure components running vulnerable kernel versions.