CVE-2026-53264

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

net/sched: act_api: use RCU with deferred freeing for action lifecycle

When NEWTFILTER and DELFILTER are run concurrently it is possible to create a race with an associated action.

Let's illustrate with CPU0 running NEWTFILTER and CPU1 running DELFILTER:

0: mutexlock() <-- holds the idr lock 0: rcureadlock() 0: p = idrfind(idr, index) <-- action p is valid (RCU protects IDR) 0: mutexunlock() <-- releases the idr lock 1: refcountdecandmutexlock() <-- refcnt 1->0, mutex held 1: idrremove(idr, index) <-- Action removed from IDR 1: mutexunlock() <-- mutex released allowing us to delete the action 1: tcfactioncleanup(p); kfree(p) <-- Kfrees p immediately, no deferral 0: refcountincnotzero(&p->tcfa_refcnt) <-- ouch, UAF p points to freed memory

This patch fixes the race condition between NEWTFILTER and DELFILTER by adding struct rcuhead to tcaction used in the deferral and introducing a call_rcu() in the delete path to defer the final kfree().

Note: this is a revert of commit d7fb60b9cafb ("netsched: get rid of tcfarcu") but also modernization/simplification to directly use kfree_rcu().

Let's illustrate the new restored code path:

0: rcureadlock() 1: refcountdecandmutexlock() <-- refcnt 1->0, mutex held 1: idrremove(idr, index) 1: mutexunlock() 1: callrcu(&p->tcfarcu, tcfactionrcufree) <-- defer kfree after grace period 0: p = idrfind(idr, index) 0: refcountincnotzero(&p->tcfarefcnt) <-- fails, refcnt already 0 1: rcureadunlock() <-- release so freeing can run after grace period

After CPU1 calls idrremove(), the object is no longer reachable through the IDR. CPU0's subsequent idrfind() will return NULL, and even if it still held a stale pointer, the immediate kfree() is now deferred until after the RCU grace period, so no UAF can occur.