CVE-2026-72404

In the Linux kernel, the following vulnerability has been resolved:

tipc: fix UAF in cleanupbearer() due to premature dstcache_destroy()

TIPC UDP media bearer teardown calls dstcachedestroy() on its replicast caches before calling synchronize_net() to wait for concurrent RCU readers (transmitters) to finish:

static void cleanupbearer(struct workstruct *work) { ... listforeachentrysafe(rcast, tmp, &ub->rcast.list, list) { dstcachedestroy(&rcast->dstcache); listdelrcu(&rcast->list); kfreercu(rcast, rcu); } ... dstcachedestroy(&ub->rcast.dstcache); udptunnelsockrelease(ub->sk); synchronize_net(); ... }

This is highly buggy because dstcachedestroy() immediately frees the per-CPU cache memory (free_percpu()) and releases the cached dst entries without any synchronization.

If a concurrent transmitter (e.g., tipcudpxmit()) is running on another CPU under RCU protection, it can call dstcacheget() concurrently, leading to: 1. Use-After-Free on the per-CPU cache pointer itself (crash). 2. "rcuref - imbalanced put()" warning if it attempts to release a dst that was concurrently released by dstcachedestroy().

Furthermore, calling kfree(ub) immediately after synchronizenet() without closing the socket first (or waiting after closing it) leaves a window where a concurrent receiver (tipcudprecv()) could start after synchronizenet(), access ub, and suffer a UAF when kfree(ub) runs.

To fix this, we must defer dstcachedestroy() and kfree(ub) until after we have ensured that no more readers can see the bearer/socket and all existing readers have finished:

1. Defer rcast entry destruction (both dstcachedestroy() and kfree()) to an RCU callback using callrcuhurry(). Using callrcuhurry() ensures the dst entries are released quickly.

2. Release the bearer socket using udptunnelsock_release() (stops new receive readers).

3. Call synchronize_net() to wait for all outstanding RCU readers (both transmit and receive) to finish.

4. Now that it is safe, call dstcachedestroy() on the main bearer cache, and free ub.

Note: 3) and 4) can be changed later in net-next to also use callrcuhurry() and get rid of the synchronize_net() latency.