[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <aV4qtP-8Iqg98wrw@redhat.com>
Date: Wed, 7 Jan 2026 10:43:16 +0100
From: Oleg Nesterov <oleg@...hat.com>
To: Qing Wang <wangqing7171@...il.com>
Cc: mingo@...hat.com, peterz@...radead.org, juri.lelli@...hat.com,
vincent.guittot@...aro.org, akpm@...ux-foundation.org,
david@...nel.org, dietmar.eggemann@....com, rostedt@...dmis.org,
bsegall@...gle.com, lorenzo.stoakes@...cle.com,
Liam.Howlett@...cle.com, vbabka@...e.cz, rppt@...nel.org,
brauner@...nel.org, mjguzik@...il.com, jack@...e.cz,
joel.granados@...nel.org, linux-kernel@...r.kernel.org,
syzbot+e0378d4f4fe57aa2bdd0@...kaller.appspotmail.com
Subject: Re: [PATCH] fork/pid: Fix use-after-free in __task_pid_nr_ns
On 01/06, Oleg Nesterov wrote:
>
> On a second thought...
>
> sched_fork() is called before perf_event_init_task(). So perhaps
> sync_child_event() could also check task->__state != TASK_NEW before
> perf_event_read_event() ?
>
> Not sure, I know nothing about perf. Would be nice if perf experts can
> take a look.
Or something else, but we can't rely on pid_alive() or ->signal != NULL
checks.
perf_event_init_task() is called soon after dup_task_struct(), so
pid_alive() is true and child->signal == current->signal.
Lets forget about use-after-free. What if perf_child_detach() paths
call __task_pid_nr_ns() before copy_signal/etc ? In this case
perf_event_pid/perf_event_tid will return the pids of the forking
process, not the child's pids.
Oleg.
Powered by blists - more mailing lists