CVE-2026-99167 in Linux
Summary
by MITRE • 10/28/2026
In the Linux kernel, the following vulnerability has been resolved:
net/sched: fix use-after-free in __tcf_action_put()
__tcf_action_put() decrements the reference count before decrementing the binding count. Another thread can free the action between these operations, causing the binding-count update to access freed memory. KASAN reports it as:
BUG: KASAN: slab-use-after-free in __tcf_action_put+0x327/0x340 Write of size 4 at addr ff11000000d46420 by task tc-put-pause/64
Hold the action IDR mutex across both counter updates and IDR removal, keeping cleanup outside the lock.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 10/28/2026
The Linux kernel networking subsystem contains a critical race condition within the traffic control action management code that leads to a use-after-free vulnerability. This flaw resides specifically in the __tcf_action_put() function, which is responsible for releasing references to network filter actions. The core technical issue stems from an incorrect ordering of operations during reference count and binding count decrements. Specifically, the original implementation decremented the action's reference count before decrementing its associated binding count. This sequence creates a dangerous window where another thread can observe that the reference count has reached zero and proceed to free the underlying memory structure for the action object.
When this premature freeing occurs, it happens while the first thread is still attempting to update the binding count. Consequently, the subsequent write operation targeting the now-freed memory address triggers a use-after-free condition. This scenario was identified through Kernel Address Sanitizer (KASAN) reports which flagged invalid writes to slab objects that had already been returned to the allocator. The specific error manifests as a four-byte write at an arbitrary kernel address by a task involved in traffic control operations, indicating direct corruption of memory structures that are no longer valid or allocated.
From a security perspective, this vulnerability aligns with CWE-416, which describes use-after-free errors resulting from improper management of object lifecycles and reference counting mechanisms. In the context of the MITRE ATT&CK framework for Linux systems, such flaws can be leveraged to achieve arbitrary code execution or denial of service by corrupting kernel memory structures. An attacker with local access who can trigger traffic control actions might exploit this race condition to destabilize the system or potentially escalate privileges if they can predict and manipulate the freed memory contents through heap spraying techniques.
The operational impact of this vulnerability includes potential system crashes, data corruption within network processing pipelines, and security breaches stemming from kernel memory exploitation. Since traffic control is a fundamental component of Linux networking used for packet shaping, policing, and classification, any instability in its core action management logic can affect the reliability of network services running on the affected systems. The race condition requires precise timing to exploit but represents a significant risk due to the high frequency with which reference counts are manipulated during normal network operation.
To mitigate this vulnerability, developers have implemented a fix that ensures atomicity and consistency in the cleanup process for traffic control actions. The solution involves holding the action IDR (Identifier) mutex across both the decrementing of the reference count and the binding count updates as well as the removal from the ID radix tree. By serializing these operations under a single lock, the window where another thread could free the object between counter decrements is eliminated. Crucially, while the locking strategy protects against the race condition during state transitions, the actual memory deallocation or cleanup logic remains outside the critical section to prevent potential deadlocks and maintain system performance. This approach adheres to best practices for concurrent programming in kernel space by minimizing lock hold times while ensuring data integrity through proper synchronization primitives.