Files
linux/include/net
Jamal Hadi Salim 5057e1aca0 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: mutex_lock() <-- holds the idr lock
 0: rcu_read_lock()
 0: p = idr_find(idr, index) <-- action p is valid (RCU protects IDR)
 0: mutex_unlock() <-- releases the idr lock
 1: refcount_dec_and_mutex_lock() <-- refcnt 1->0, mutex held
 1: idr_remove(idr, index) <-- Action removed from IDR
 1: mutex_unlock() <-- mutex released allowing us to delete the action
 1: tcf_action_cleanup(p); kfree(p) <-- Kfrees p immediately, no deferral
 0: refcount_inc_not_zero(&p->tcfa_refcnt) <-- ouch, UAF p points to freed memory

This patch fixes the race condition between NEWTFILTER and DELFILTER by
adding struct rcu_head to tc_action 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 d7fb60b9ca ("net_sched: get rid of tcfa_rcu")
but also modernization/simplification to directly use kfree_rcu().

Let's illustrate the new restored code path:

 0: rcu_read_lock()
 1: refcount_dec_and_mutex_lock() <-- refcnt 1->0, mutex held
 1: idr_remove(idr, index)
 1: mutex_unlock()
 1: call_rcu(&p->tcfa_rcu, tcf_action_rcu_free) <-- defer kfree after grace period
 0: p = idr_find(idr, index)
 0: refcount_inc_not_zero(&p->tcfa_refcnt) <-- fails, refcnt already 0
 1: rcu_read_unlock() <-- release so freeing can run after grace period

After CPU1 calls idr_remove(), the object is no longer reachable through the IDR.
CPU0's subsequent idr_find() 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.

Fixes: d7fb60b9ca ("net_sched: get rid of tcfa_rcu")
Suggested-by: Jakub Kicinski <kuba@kernel.org>
Reported-by: Kyle Zeng <kylebot@openai.com>
Tested-by: Victor Nogueira <victor@mojatatu.com>
Tested-by: syzbot@syzkaller.appspotmail.com
Signed-off-by: Jamal Hadi Salim <jhs@mojatatu.com>
Tested-by: Kyle Zeng <kylebot@openai.com>
Reviewed-by: Pedro Tammela <pctammela@mojatatu.com>
Reviewed-by: Eric Dumazet <edumazet@google.com>
Reviewed-by: Victor Nogueira <victor@mojatatu.com>
Link: https://patch.msgid.link/20260531160812.68020-1-jhs@mojatatu.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-01 16:52:08 -07:00
..
2025-04-24 17:03:45 -07:00
2025-07-08 18:05:25 -07:00
2024-05-08 10:35:09 +01:00
2024-08-26 09:37:23 -07:00
2024-11-13 18:49:50 -08:00
2024-08-26 09:37:23 -07:00
2025-08-26 17:34:31 -07:00
2026-01-21 19:28:32 -08:00
2024-05-07 01:35:55 +02:00
2024-08-26 09:37:23 -07:00
2024-12-06 17:43:08 -08:00
2024-08-26 09:37:23 -07:00
2025-04-15 08:21:46 -07:00
2025-09-18 12:32:06 +02:00
2024-08-26 09:37:23 -07:00
2024-08-26 09:37:23 -07:00
2025-04-11 18:58:10 -07:00
2025-07-04 09:32:35 +02:00
2024-05-30 18:29:38 -07:00
2025-09-08 18:06:21 -07:00
2025-07-11 11:00:57 -07:00
2023-07-28 14:07:59 -07:00
2026-03-13 18:57:44 -07:00
2026-04-06 18:43:51 -07:00
2026-03-16 19:28:21 -07:00