CVE-2026-98596 in Linux
Summary
by MITRE • 10/18/2026
In the Linux kernel, the following vulnerability has been resolved:
ipv6: Fix dst leak for uncached routes.
ip6_route_output_flags(), ip6_rt_put_flags(), and ip6_dst_check() detect an uncached route by list_empty(&rt->dst.rt_uncached), which replaced the static DST_NOCACHE flag check in commit a4c2fd7f7891 ("net: remove DST_NOCACHE flag").
When a device is unregistered, rt6_uncached_list_flush_dev() unlinks uncached routes tied to the device from rt6_uncached_list.
Previously, they were moved to another list with list_move() (__list_del_entry() + list_add()), and since commit 98aa546af5e4 ("inet: remove (struct uncached_list)->quarantine"), the routes are just unlinked with list_del_init().
If list_del_init() runs concurrently, list_empty() evaluates to true; ip6_route_output_flags() calls dst_hold_safe() incorrectly and ip6_rt_put_flags() skips ip6_rt_put(), leaking dst, and thus dev tied via rt->from as well.
The same race is partially fixed by commit 9a6f0c4d5796 ("dst: fix races in rt6_uncached_list_del() and rt_del_uncached_list()").
Let's check rt6->dst.rt_uncached_list instead.
Note that IPv4 does not have the same issue.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 10/18/2026
The Linux kernel contains a concurrency-related vulnerability within its Internet Protocol version 6 networking stack, specifically affecting the management of uncached routing entries. This flaw arises from a race condition involving the detection and cleanup of routes that are not stored in the main cache but remain active on specific network devices. The core issue stems from how the kernel determines whether a route is uncached versus cached after the removal of the static DST_NOCACHE flag. Previously, the system relied on this flag to identify such routes, but modern implementations utilize list emptiness checks against an internal structure known as rt_uncached_list to make this determination. This architectural shift introduced subtle timing dependencies that can lead to resource leaks under specific concurrent execution scenarios.
The vulnerability manifests when a network device is unregistered or removed from the system. During this process, the kernel invokes functions such as ip6_route_output_flags and ip6_dst_check to evaluate existing routes associated with that device. These functions rely on list_empty checks against rt->dst.rt_uncached to verify if a route remains in the uncached state. Simultaneously, the function rt6_uncached_list_flush_dev is responsible for unlinking these uncached routes from the global rt6_uncached_list when their associated device disappears. The critical flaw occurs because the unlinking operation uses list_del_init, which modifies the list structure atomically but does not prevent concurrent readers from observing an intermediate state where the list appears empty even though the route object is still being processed or referenced by another thread.
When this race condition triggers, a reader thread may observe that the uncached list entry has been removed and consequently evaluate the emptiness check as true. This false positive leads ip6_route_output_flags to incorrectly invoke dst_hold_safe, assuming the route is valid and needs reference counting increments. Conversely, it causes ip6_rt_put_flags to skip the necessary cleanup call of ip6_rt_put because it mistakenly believes the route has already been handled or removed from the uncached tracking mechanism. The direct consequence of this logic error is a memory leak involving the dst structure, which represents the destination cache entry in the kernel networking subsystem.
The impact of this vulnerability extends beyond simple memory consumption. Because each leaked dst structure holds references to underlying network devices via the rt->from pointer, persistent leaks can lead to resource exhaustion and potential denial of service conditions for network operations on that device. Over time, as more routes are improperly handled during device unregistration or high-concurrency routing lookups, the kernel may consume excessive amounts of memory, potentially impacting system stability and performance. Although previous commits attempted to address similar race conditions in related functions like rt6_uncached_list_del, this specific interaction between route output flags and put operations remained unresolved until a targeted fix was applied to check the correct list context instead of relying on the volatile emptiness state during concurrent access.
From a classification perspective, this vulnerability aligns with CWE-401, which describes memory leaks resulting from improper release of allocated resources due to logic errors or race conditions. In terms of attack vectors and defensive mapping, it relates to ATT&CK techniques involving resource exhaustion, as an attacker could potentially trigger repeated device unregistrations and route lookups in a controlled environment to accelerate the leak rate. While IPv4 implementations do not exhibit this specific flaw due to differences in their routing cache management architecture, the issue highlights the complexity of maintaining consistency across concurrent kernel subsystems during state transitions like interface removal.
Mitigation strategies primarily involve applying the upstream Linux kernel patches that correct the list checking logic and ensure proper reference counting for dst structures regardless of concurrency states. System administrators should prioritize updating to kernel versions where this race condition is resolved, particularly in environments with frequent network device configuration changes or high-throughput routing scenarios. Additionally, monitoring system memory usage patterns associated with networking subsystems can help detect early signs of such leaks before they escalate into service-affecting resource exhaustion events.