CVE-2026-74609 in Linux
Summary
by MITRE • 08/22/2026
In the Linux kernel, the following vulnerability has been resolved:
tipc: read le->link under the node lock in tipc_node_link_down()
tipc_node_link_down() caches the link pointer before taking n->lock:
struct tipc_link *l = le->link; /* unlocked */
if (!l) return; tipc_node_write_lock(n); if (!tipc_link_is_establishing(l)) { /* deref l */
... tipc_link_reset(l); /* write into l */ if (delete) {
kfree(l); le->link = NULL;
The delete=true caller frees that very object under n->lock, so the lock does not protect the cached pointer against it:
- CPU A, delete=false: tipc_rcv() on TIPC_LINK_DOWN_EVT, or the link supervision timer via tipc_node_timeout(), reads l unlocked and then dereferences it under n->lock; - CPU B, delete=true: netlink TIPC_NL_BEARER_DISABLE -> bearer_disable() -> tipc_node_delete_links() -> tipc_node_link_down(n, bearer_id, true) -> kfree(l).
The link is freed with plain kfree(), not kfree_rcu(), and for UDP bearers disable_media() only schedules the asynchronous cleanup_bearer() work, so its synchronize_net() runs after the links are already gone. An in-flight CPU A that has read l therefore dereferences freed memory once B frees it: a use-after-free read in tipc_link_is_establishing(), and a use-after-free write via tipc_link_reset() on the establishing branch.
The following trace was captured on 7.2.0-rc5-00284-gaf39eb111ce6:
BUG: KASAN: slab-use-after-free in tipc_link_is_establishing (net/tipc/link.c:285) Read of size 4 at addr ffff88802e2aa068 by task swapper/2/0 tipc_link_is_establishing (net/tipc/link.c:285) tipc_node_link_down (net/tipc/node.c:1076) tipc_node_timeout (net/tipc/node.c:843) Allocated by task 9549: tipc_link_create (net/tipc/link.c:490) tipc_node_check_dest (net/tipc/node.c:1279) tipc_disc_rcv (net/tipc/discover.c:252) tipc_udp_recv (net/tipc/udp_media.c:389) Freed by task 9549: tipc_node_link_down (net/tipc/node.c:1084) tipc_node_delete_links (net/tipc/node.c:1320) bearer_disable (net/tipc/bearer.c:414) __tipc_nl_bearer_disable (net/tipc/bearer.c:992)
Move the le->link read inside tipc_node_write_lock(), so it is serialised against the kfree() in the delete path. A racing teardown now either has not run yet, and we see a valid link, or has already run, and we see NULL.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 08/22/2026
The Linux kernel's Transparent Inter-Process Communication (TIPC) subsystem contains a critical use-after-free vulnerability within the tipc_node_link_down function, stemming from improper synchronization of shared data structures during node teardown operations. This flaw allows for race conditions between link state inspection and memory deallocation, potentially leading to system instability or arbitrary code execution if exploited by an attacker with sufficient privileges to trigger bearer disable events while link supervision timers are active. The vulnerability is rooted in the way the kernel handles concurrent access to TIPC link pointers without adequate locking mechanisms, exposing a classic concurrency bug that undermines the integrity of memory management within the network stack.
The technical flaw arises from a specific sequence of operations where the code caches a pointer to a tipc_link structure before acquiring the node lock. Specifically, the variable l is assigned the value of le->link while still in an unlocked context. Subsequently, if the delete flag is true, the function proceeds to free this exact memory region using kfree() after acquiring the write lock on n->lock. However, another CPU core may be executing a different path where it reads the cached link pointer without holding any locks and then attempts to dereference it under the node lock. Because the initial read of le->link occurred outside the protection of the spinlock, there is no guarantee that the memory pointed to by l remains valid when it is accessed later in tipc_link_is_establishing or tipc_link_reset. This creates a window where one thread frees the object while another continues to use it, resulting in a classic use-after-free condition.
The operational impact of this vulnerability is severe, as evidenced by kernel crash traces showing slab-use-after-free errors within tipc_link_is_establishing. When CPU A executes the link supervision timer or receives a TIPC_LINK_DOWN_EVT, it reads the cached pointer and later dereferences it to check if the link is establishing or to reset its state. Simultaneously, CPU B may process a netlink command to disable a bearer, which triggers tipc_node_delete_links and subsequently calls tipc_node_link_down with delete set to true. This causes CPU B to free the memory associated with that link pointer. If CPU A dereferences this freed memory after it has been returned to the slab allocator but before it is reused or zeroed out by the kernel, undefined behavior occurs. In practice, this manifests as a kernel panic due to accessing invalid memory addresses, leading to denial of service against systems relying on TIPC for inter-process communication over UDP bearers.
This vulnerability aligns with CWE-416, Use After Free, where software continues to use a pointer after it has been freed, and also relates to CWE-362, Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition'). From an ATT&CK perspective, this type of kernel-level race condition can be leveraged for privilege escalation or denial of service attacks against Linux-based infrastructure. The lack of proper synchronization allows an attacker who can influence the timing of bearer disable operations to trigger a crash or potentially exploit the freed memory if they have control over its reallocation contents, although the primary observed impact is system instability through kernel oopses and panics.
The resolution involves moving the read operation for le->link inside the critical section protected by tipc_node_write_lock(). By serializing the access to the link pointer against the kfree() call in the delete path, the race condition is eliminated. This ensures that if a racing teardown has not yet run, the code sees a valid link structure; conversely, if the teardown has already completed and freed the memory, the lock acquisition will prevent the stale read from occurring because the state would have been updated to NULL or the operation would be blocked until safe access is possible. This change enforces proper mutual exclusion, ensuring that all reads of le->link are atomic with respect to writes and frees performed under the node lock.
To mitigate this vulnerability in environments where kernel updates may not be immediately available, administrators should consider disabling TIPC if it is not strictly required for their specific use case. Additionally, monitoring system logs for slab-use-after-free errors can help detect potential exploitation attempts or instability caused by this race condition. It is crucial to apply the latest security patches that include fixes for tipc_node_link_down as soon as they are released by distribution vendors. Regular auditing of kernel configurations and minimizing attack surfaces by disabling unused network protocols further reduces the risk associated with such low-level concurrency bugs in the Linux networking stack.