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.