CVE-2026-99246 in Linux
Summary
by MITRE • 11/03/2026
In the Linux kernel, the following vulnerability has been resolved:
tipc: protect node reset trace dump with node lock
The tipc_node_reset_links trace event asks tipc_node_dump() to walk the node's link entries. Unlike the other node events that request link data, this event runs without the node lock.
This permits bearer teardown to free a link while the trace callback is dumping it:
CPU 0 CPU 1 trace_tipc_node_reset_links() tipc_node_dump() l = n->links[0].link
tipc_node_write_lock() kfree(l) n->links[0].link = NULL
tipc_node_write_unlock() tipc_link_dump(l)
tipc_link_dump() then dereferences the stale pointer. KASAN reported:
BUG: KASAN: slab-use-after-free in tipc_link_dump Read of size 4 by task poc/115 Call Trace: tipc_link_dump+0x10cb/0x16b0 tipc_node_dump+0x4bb/0x740 trace_event_raw_event_tipc_node_class+0x258/0x360 tipc_node_reset_links+0x14d/0x1a0 tipc_rcv+0x13f5/0x3030 tipc_udp_recv+0x4e3/0x670 Allocated by task 0: tipc_link_create+0x1e1/0x1020 tipc_node_check_dest+0x7d2/0x11a0 tipc_disc_rcv+0xdbf/0x1430 Freed by task 89: kfree+0x131/0x3c0 tipc_node_link_down+0x267/0x4b0 tipc_node_delete_links+0xec/0x160 bearer_disable+0x107/0x260
Take the node write lock around the trace event. This serializes the dump against tipc_node_link_down(delete=true), which frees the link under the same write lock.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 11/03/2026
The vulnerability identified in the Linux kernel's Transparent Inter-process Communication (TIPC) subsystem represents a critical concurrency flaw rooted in improper synchronization during memory access operations. Specifically, this issue affects the trace event mechanism used for debugging and monitoring node resets within the TIPC protocol stack. The core technical failure lies in the execution context of the tipc_node_reset_links trace event, which invokes the tipc_node_dump function to iterate through a node's link entries. Unlike other similar node events that correctly acquire necessary synchronization primitives before accessing shared data structures, this specific trace handler operates without holding the node write lock. This omission creates a race condition window where the kernel’s memory management and concurrency control mechanisms are not properly aligned with the read operations performed by the tracing infrastructure.
The operational impact of this flaw is severe, manifesting as a use-after-free error that can lead to system instability or potential exploitation for arbitrary code execution under specific conditions. The sequence of events begins when CPU 0 initiates the trace_tipc_node_reset_links function, which calls tipc_node_dump to retrieve link information. Simultaneously, on CPU 1, the bearer teardown process triggers a call to tipc_node_link_down with a delete flag set to true. This operation acquires the node write lock, frees the memory associated with the specific link entry using kfree, and then releases the lock by setting the pointer in n->links[0] to NULL. Because CPU 0 is not holding this same write lock during its dump operation, it may proceed to dereference a stale pointer that has already been freed or is in the process of being invalidated. The Kernel Address Sanitizer (KASAN) explicitly flags this as a slab-use-after-free bug, where tipc_link_dump attempts to read data from memory that was previously allocated by tipc_link_create but subsequently freed by bearer_disable via node_delete_links and node_link_down routines.
From a security classification perspective, this vulnerability aligns with CWE-416: Use After Free, as the system accesses memory after it has been made available for reuse without ensuring data integrity or pointer validity. Furthermore, in the context of the MITRE ATT&CK framework, this flaw relates to techniques involving exploitation of race conditions and improper handling of shared resources, which can be leveraged by an attacker with local access to trigger specific network state changes that induce the crash or potentially manipulate kernel memory structures. The lack of atomicity between checking the link status and accessing its contents allows for a time-of-check-to-time-of-use (TOCTOU) scenario where the state of the resource changes unexpectedly during execution.
To mitigate this vulnerability, the recommended remediation is to enforce strict serialization by acquiring the node write lock around the entire duration of the trace event callback. By taking the tipc_node_write_lock before calling tipc_node_dump and releasing it only after the dump operation completes, the kernel ensures that no concurrent bearer teardown or link deletion can occur while the tracing infrastructure is reading from the data structure. This change guarantees mutual exclusion between readers accessing node links for diagnostic purposes and writers modifying those same structures during network state transitions such as bearer disabling or node reset procedures. System administrators should apply this patch to their Linux kernels immediately, particularly in environments where TIPC is actively used for high-performance inter-process communication over UDP or other supported transports, to prevent potential denial of service conditions arising from kernel panics triggered by these race conditions.