Re: [PATCH v2 2/2] pid: fix cad_pid use-after-free race

From: Bradley Morgan

Date: Sat Jul 18 2026 - 10:28:31 EST


On July 18, 2026 3:13:37 PM GMT+01:00, Oleg Nesterov <oleg@xxxxxxxxxx>
wrote:
>On 07/18, Bradley Morgan wrote:
>>
>> On July 18, 2026 2:19:57 PM GMT+01:00, Oleg Nesterov <oleg@xxxxxxxxxx>
>>
>> > Hmm. Why do we need get/put_pid() ? I think that
>> >
>> > rcu_read_lock();
>> > ret = kill_pid(rcu_dereference(cad_pid), sig, priv);
>> > rcu_read_unlock();
>> >
>> > return ret;
>> >
>> > should work just fine?
>>
>> youre right that the get/put is redundant. kill_pid() doesnt sleep, it
>just
>> grabs tasklist_lock,
>
>(no it doesn't take tasklist)
>
>> but i dont think either form is actually safe, and thats the bit id like
>> Cen to address. rcu_read_lock() only protects the pid if the freeing
>side
>> defers to a grace period. on the cad_pid path it doesnt:
>>
>> proc_do_cad_pid():
>> put_pid(xchg(&cad_pid, new_pid));
>
>I must have missed something.
>
>But this patch adds synchronize_rcu() before the final put_pid() ?
>
>And. If kill_pid(rcu_dereference(cad_pid)) was not safe under
>rcu_read_lock(),
>then get_pid(rcu_dereference(cad_pid)) would be equally unsafe?
>
>Oleg.
>
>


oops, my bad. Brainfog.

Thanks!