CVE-2026-89488 in Linux
Summary
by MITRE • 09/12/2026
In the Linux kernel, the following vulnerability has been resolved:
openvswitch: Fix CT limit teardown use-after-free
Packet processing uses CT limit state under RCU, while netns teardown frees that state under ovs_mutex. The CT limit pointer was neither removed from readers nor protected by a grace period, allowing packet processing to dereference the freed state.
An unprivileged user can trigger this bug from a user and network namespace, causing a slab-use-after-free in ovs_ct_execute() when the netns is torn down.
Publish the CT limit pointer through RCU, remove it before teardown, and wait for readers before freeing its contents. Keep ovs_mutex around individual CT limit updates, and use the RCU read-side lock while GET traverses the RCU-protected limit lists.
Netns teardown detaches the RCU-protected CT limit state in the pernet .pre_exit callback while holding ovs_mutex. The pernet core guarantees an RCU grace period between the .pre_exit and .exit callbacks, so the .exit callback completes the teardown without adding any extra synchronization.
The netlink command handlers do not need NULL checks because the userspace netlink socket holds an active reference to its network namespace while a request is processed. The per-netns exit path therefore cannot run concurrently with SET, DEL, or GET for that socket's namespace.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/12/2026
This vulnerability represents a critical use-after-free flaw within the Linux kernel’s Open vSwitch implementation, specifically affecting connection tracking limit state management. The core issue stems from an improper synchronization mechanism between packet processing threads and network namespace teardown procedures. Under normal operation, the Connection Tracking (CT) limit state is accessed using Read-Copy-Update semantics to allow concurrent readers without blocking writers. However, during the cleanup phase of a network namespace, the kernel attempts to free this state while holding only the ovs_mutex lock. This approach fails because it does not account for ongoing packet processing operations that may still hold references to the CT limit data structure via RCU read-side critical sections. Consequently, when the netns teardown process frees the memory associated with the CT limit pointer, any concurrent packet flow attempting to access this state will dereference a freed memory address, leading to undefined behavior and potential system instability.
The operational impact of this vulnerability is significant as it allows an unprivileged user to trigger a slab-use-after-free condition from within both a standard user namespace and a network namespace. By creating and subsequently destroying specific network configurations, an attacker can force the race condition where the kernel frees the CT limit state while packet processing threads are still actively reading from it. This exploitation vector does not require elevated privileges, making it accessible to local users who have been granted limited networking capabilities. The resulting memory corruption can lead to kernel panics, denial of service conditions by crashing the host system or specific virtual network instances, and potentially arbitrary code execution if an attacker can carefully control the contents of the freed slab cache to overwrite function pointers or other critical data structures during subsequent allocations.
From a technical remediation perspective, the fix involves restructuring how the CT limit pointer is managed throughout its lifecycle. The solution requires publishing the CT limit pointer through proper RCU mechanisms and ensuring it is removed from active readers before any teardown operations begin. Crucially, the kernel must wait for all existing RCU read-side critical sections to complete via a grace period before freeing the underlying data structures. This ensures that no packet processing thread can access memory that has been returned to the system allocator. Additionally, the ovs_mutex is retained around individual CT limit updates to maintain consistency during modifications, while GET operations traverse the RCU-protected lists using appropriate read-side locks. The netns teardown process now detaches the RCU-protected state in the pernet pre-exit callback under the protection of ovs_mutex, leveraging the kernel’s guarantee that an RCU grace period exists between pre-exit and exit callbacks to safely complete the cleanup without additional complex synchronization primitives.
This vulnerability is categorized under CWE-416, Use After Free, which describes situations where a program uses memory after it has been freed, leading to unpredictable behavior. In terms of attack classification within the MITRE ATT&CK framework, this flaw aligns with Tactic TA0005 Defense Evasion and specifically techniques related to exploiting race conditions or improper resource management that can lead to privilege escalation or denial of service. The lack of proper synchronization between concurrent access patterns is a common root cause in kernel-level vulnerabilities, highlighting the importance of rigorous memory safety checks in high-performance networking subsystems like Open vSwitch. Mitigation strategies for system administrators include applying vendor-provided kernel patches as soon as they become available and restricting network namespace creation privileges to trusted users where possible. For environments running vulnerable versions, monitoring for unusual crashes or performance degradation related to OVS flows can serve as an indicator of potential exploitation attempts until the underlying synchronization issues are resolved through software updates.