CVE-2026-74609: tipc: read le->link under the node lock in tipc_node_link_down()
In the Linux kernel, the following vulnerability has been resolved:
tipc: read le->link under the node lock in tipcnodelinkdown()
tipcnodelinkdown() caches the link pointer before taking n->lock:
struct tipclink l = le->link; / unlocked /
if (!l) return; tipcnodewritelock(n); if (!tipclinkisestablishing(l)) { / deref l / ... tipclinkreset(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: tipcrcv() on TIPCLINKDOWNEVT, or the link supervision timer via tipcnodetimeout(), reads l unlocked and then dereferences it under n->lock; - CPU B, delete=true: netlink TIPCNLBEARERDISABLE -> bearerdisable() -> tipcnodedeletelinks() -> tipcnodelinkdown(n, bearerid, true) -> kfree(l).
The link is freed with plain kfree(), not kfreercu(), and for UDP bearers disablemedia() only schedules the asynchronous cleanupbearer() work, so its synchronizenet() 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 tipclinkisestablishing(), and a use-after-free write via tipclinkreset() on the establishing branch.
The following trace was captured on 7.2.0-rc5-00284-gaf39eb111ce6:
BUG: KASAN: slab-use-after-free in tipclinkisestablishing (net/tipc/link.c:285) Read of size 4 at addr ffff88802e2aa068 by task swapper/2/0 tipclinkisestablishing (net/tipc/link.c:285) tipcnodelinkdown (net/tipc/node.c:1076) tipcnodetimeout (net/tipc/node.c:843) Allocated by task 9549: tipclinkcreate (net/tipc/link.c:490) tipcnodecheckdest (net/tipc/node.c:1279) tipcdiscrcv (net/tipc/discover.c:252) tipcudprecv (net/tipc/udpmedia.c:389) Freed by task 9549: tipcnodelinkdown (net/tipc/node.c:1084) tipcnodedeletelinks (net/tipc/node.c:1320) bearerdisable (net/tipc/bearer.c:414) tipcnlbearerdisable (net/tipc/bearer.c:992)
Move the le->link read inside tipcnodewritelock(), 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.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade to a fixed release to a version that resolves this vulnerability.
Fixed in 6.6.152.1-1 - Upgrade
Upgrade
Linux kernel (net/tipc)to a version that resolves this vulnerability.Fixed in 7.2.0-rc5-00284-gaf39eb111ce6
Event History
Frequently Asked Questions
What concurrent activity is required for the use-after-free to occur?
One CPU must enter tipc_node_link_down() with delete=false through a TIPC link-down event or the link supervision timer and read the link pointer before taking n->lock. Concurrently, another CPU must disable a bearer, causing tipc_node_delete_links() to call tipc_node_link_down() with delete=true and free that same link.
Does the node lock protect against this race?
No. The affected path caches le->link before acquiring n->lock, so it can later dereference a pointer that was freed by the delete=true path while holding that lock.
Does UDP bearer cleanup synchronization prevent the stale-pointer dereference?
No. For UDP bearers, disable_media() schedules asynchronous cleanup_bearer() work, and its synchronize_net() runs only after the links have already been removed and freed.
What code condition indicates the affected behavior is present?
The vulnerable behavior is present when tipc_node_link_down() reads and stores le->link before taking the node lock, then dereferences or resets the cached pointer after acquiring the lock. The delete path frees the link with plain kfree() and clears le->link.