linux-kernel - Re: [PATCH] fork/pid: Fix use-after-free in __task_pid_nr

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <aVzqzG4MYaJYbBVd@redhat.com>
Date: Tue, 6 Jan 2026 11:58:20 +0100
From: Oleg Nesterov <oleg@...hat.com>
To: Qing Wang <wangqing7171@...il.com>
Cc: Liam.Howlett@...cle.com, akpm@...ux-foundation.org, brauner@...nel.org,
	bsegall@...gle.com, david@...nel.org, dietmar.eggemann@....com,
	jack@...e.cz, joel.granados@...nel.org, juri.lelli@...hat.com,
	linux-kernel@...r.kernel.org, lorenzo.stoakes@...cle.com,
	mingo@...hat.com, mjguzik@...il.com, peterz@...radead.org,
	rostedt@...dmis.org, rppt@...nel.org,
	syzbot+e0378d4f4fe57aa2bdd0@...kaller.appspotmail.com,
	vbabka@...e.cz, vincent.guittot@...aro.org
Subject: Re: [PATCH] fork/pid: Fix use-after-free in __task_pid_nr_ns

On 01/06, Qing Wang wrote:
>
> On Tue, 06 Jan 2026 at 17:04, Oleg Nesterov <oleg@...hat.com> wrote:
> > At first glance this is racy. Can't task->signal be freed right after
> > the check?
> >
> > And... Can't we make another fix? If copy_process() fails and does
> > free_signal_struct(), the child has not been added to rcu protected
> > lists and init_task_pid(child) was not called yet.
> >
> > So perhaps something like the patch below can work?
> >
> > Oleg.
> > ---
> >
> > --- x/kernel/events/core.c
> > +++ x/kernel/events/core.c
> > @@ -1422,16 +1422,17 @@ unclone_ctx(struct perf_event_context *c
> >  static u32 perf_event_pid_type(struct perf_event *event, struct task_struct *p,
> >  				enum pid_type type)
> >  {
> > -	u32 nr;
> > +	u32 nr = 0;
> >  	/*
> >  	 * only top level events have the pid namespace they were created in
> >  	 */
> >  	if (event->parent)
> >  		event = event->parent;
> >
> > -	nr = __task_pid_nr_ns(p, type, event->ns);
> > +	if (pid_alive(p))
> > +		nr = __task_pid_nr_ns(p, type, event->ns);
> >  	/* avoid -1 if it is idle thread or runs in another ns */
> > -	if (!nr && !pid_alive(p))
> > +	if (!nr)
> >  		nr = -1;
> >  	return nr;
> >  }
>
> Sorry, please ignore my previous reply. I've reconsidered your code, and
> using pid_alive() to check the validity of tsk->signal is actually correct.
> The pid is assigned after copy_signal(), so if a task has a PID, its
> tsk->signal memory is guaranteed to be valid.

Yes, if the child wasn't fully created then init_task_pid(child) was not
called so pid_alive(p) can't be true.

OK, if you agree with this approach, can you make V2? Or do you prefer
another approach?

The patch above is not 100% correct wrt "avoid -1 ...", but it seems that
this can be fixed.

Oleg.