linux-kernel - Re: [PATCH] procfs: fix missing RCU protection when reading real_parent in do_task

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <zgqq2et7hf4fh3ggzvvcfmr5wkwoqjfzftxpdedinwinpr4xun@jrbtkbd5ig6n>
Date: Tue, 27 Jan 2026 19:49:11 +0100
From: Mateusz Guzik <mjguzik@...il.com>
To: Oleg Nesterov <oleg@...hat.com>
Cc: alexjlzheng@...il.com, usamaarif642@...il.com, david@...nel.org, 
	akpm@...ux-foundation.org, lorenzo.stoakes@...cle.com, alexjlzheng@...cent.com, 
	mingo@...nel.org, ruippan@...cent.com, linux-kernel@...r.kernel.org, 
	linux-fsdevel@...r.kernel.org
Subject: Re: [PATCH] procfs: fix missing RCU protection when reading
 real_parent in do_task_stat()

On Tue, Jan 27, 2026 at 06:25:25PM +0100, Oleg Nesterov wrote:
> On 01/27, alexjlzheng@...il.com wrote:
> > --- a/fs/proc/array.c
> > +++ b/fs/proc/array.c
> > @@ -528,7 +528,9 @@ static int do_task_stat(struct seq_file *m, struct pid_namespace *ns,
> >  		}
> >
> >  		sid = task_session_nr_ns(task, ns);
> > -		ppid = task_tgid_nr_ns(task->real_parent, ns);
> > +		rcu_read_lock();
> > +		ppid = task_tgid_nr_ns(rcu_dereference(task->real_parent), ns);
> > +		rcu_read_unlock();
> 
> But this can't really help. If task->real_parent has already exited and
> it was reaped, then it is actually "Too late!" for rcu_read_lock().
> 
> Please use task_ppid_nr_ns() which does the necessary pid_alive() check.
> 

That routine looks bogus in its own right though.

Suppose it fits the time window between the current parent exiting and
the task being reassigned to init. Then you transiently see 0 as the pid,
instead of 1 (or whatever). This reads like a bug to me.

But suppose task_ppid_nr_ns() managed to get the right value at the
time. As per usual, such an exit + reaping could have happened before
the caller even looks at the returned pid.

Or to put it differently, imo the check in the routine not only does not
help, but introduces a corner case with a bogus result.

It probably should do precisely the same thing proposed in this patch,
as in:
	rcu_read_lock();
	ppid = task_tgid_nr_ns(rcu_dereference(task->real_parent), ns);
	rcu_read_unlock();