Re: [PATCH] pid: fix cad_pid use-after-free race in proc_do_cad_pid()
From: Bradley Morgan
Date: Fri Jul 17 2026 - 19:16:07 EST
Hi Cen,
Applies to master, context matches. The race is real..
[re: what the synchronize_rcu() is accomplishing]
put_pid() frees synchronously via kmem_cache_free(), and pid_cachep is
not SLAB_TYPESAFE_BY_RCU. So the writer has to wait out RCU readers
before the free, and synchronize_rcu() is that wait. Its standing in for
the call_rcu() we cant use, free_pid() owns pid->rcu. Correct,
just not like very obvious. please put a one line comment above it
saying exactly that.
> + rcu_read_lock();
> tmp_pid = pid_vnr(cad_pid);
> + rcu_read_unlock();
plain load. Use rcu_dereference() and annotate cad_pid __rcu, otherwise
sparse cant see any of this.
> - put_pid(xchg(&cad_pid, new_pid));
> + old_pid = xchg(&cad_pid, new_pid);
> + synchronize_rcu();
> + put_pid(old_pid);
ok, fine. xchg() is fully ordered, one writer per old_pid, no double put.
but this fixes one of two readers. kill_cad_pid() in sched/signal.h has
the same unprotected load and is reachable from ctrl_alt_del(), thats
hardirq context, so your grace period does nothing for it. Deinline it
into kernel/pid.c and do e.g:
rcu_read_lock();
pid = get_pid(rcu_dereference(cad_pid));
rcu_read_unlock();
ret = kill_pid(pid, sig, priv);
put_pid(pid);
Please make it a two patch series, deinline with no functional change, then
fix both readers.
Nits:
The Fixes: tag LGTM, before 9ec52099e4b8 there was no struct to free. If
you want CC stable, add a line in
the changelog about impact: iirc it is root only (the sysctl is
0600) and only when cad_pid holds the last ref of an exited task. Subject
prefix should be
"pid:". Keep the vN changelog below the ---.
with those addressed, please add:
Reviewed-by: Bradley Morgan <include@xxxxxxxxx>
Thanks!