From: Kees Cook <kees@kernel.org>
To: Qing Wang <wangqing7171@gmail.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
David Hildenbrand <david@kernel.org>,
Lorenzo Stoakes <lorenzo.stoakes@oracle.com>,
"Liam R . Howlett" <Liam.Howlett@oracle.com>,
Vlastimil Babka <vbabka@suse.cz>, Mike Rapoport <rppt@kernel.org>,
Suren Baghdasaryan <surenb@google.com>,
Michal Hocko <mhocko@suse.com>, Ingo Molnar <mingo@redhat.com>,
Peter Zijlstra <peterz@infradead.org>,
Juri Lelli <juri.lelli@redhat.com>,
Vincent Guittot <vincent.guittot@linaro.org>,
Dietmar Eggemann <dietmar.eggemann@arm.com>,
Steven Rostedt <rostedt@goodmis.org>,
Ben Segall <bsegall@google.com>, Mel Gorman <mgorman@suse.de>,
Valentin Schneider <vschneid@redhat.com>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
syzbot+e0378d4f4fe57aa2bdd0@syzkaller.appspotmail.com
Subject: Re: [PATCH] fork/pid: Fix use-after-free in __task_pid_nr_ns
Date: Wed, 7 Jan 2026 12:39:37 -0800 [thread overview]
Message-ID: <202601071238.F86C2B8@keescook> (raw)
In-Reply-To: <20260105045609.1764387-1-wangqing7171@gmail.com>
On Mon, Jan 05, 2026 at 12:56:09PM +0800, Qing Wang wrote:
> Syzbot reported a slab-use-after-free issue in __task_pid_nr_ns:
>
> BUG: KASAN: slab-use-after-free in __task_pid_nr_ns+0x1e4/0x490...
> Read of size 8 at addr ffff88807f8058a8 by task syz.1.574/8108
>
> The race condition occurs between the failure path of copy_process() and
> getting the PIDTYPE_TGID via __task_pid_nr_ns().
>
> Bug timeline:
> Task B
> perf_event_open()
> Task A <--------------------------- clone()
> copy_process()
> perf_event_init_task()
> ...
> one copy failed
> free_signal_struct() close(event_fd)
> perf_child_detach()
> __task_pid_nr_ns()
> access child task->signal
>
> This is fixed by:
> 1. Setting task->signal = NULL in the failure cleanup path of copy_process.
> 2. Adding a null check for task->signal before accessing PIDTYPE_TGID from
> task->signal.
>
> Note: This bug was reported by syzbot without a reproducer.
> The fix is based on code inspection and race condition analysis.
It seems like there is synchronization missing between the task->signal
assignment and its check in task_pid_ptr? Aren't there other ways of
checking if a task is dead? This change doesn't look right to me...
-Kees
>
> Reported-by: syzbot+e0378d4f4fe57aa2bdd0@syzkaller.appspotmail.com
> Closes: https://syzkaller.appspot.com/bug?extid=e0378d4f4fe57aa2bdd0
> Signed-off-by: Qing Wang <wangqing7171@gmail.com>
> ---
> kernel/fork.c | 8 ++++++--
> kernel/pid.c | 6 +++---
> 2 files changed, 9 insertions(+), 5 deletions(-)
>
> diff --git a/kernel/fork.c b/kernel/fork.c
> index b1f3915d5f8e..72b9b37a96c8 100644
> --- a/kernel/fork.c
> +++ b/kernel/fork.c
> @@ -1975,6 +1975,7 @@ __latent_entropy struct task_struct *copy_process(
> struct file *pidfile = NULL;
> const u64 clone_flags = args->flags;
> struct nsproxy *nsp = current->nsproxy;
> + struct signal_struct *free_sig = NULL;
>
> /*
> * Don't allow sharing the root directory with processes in a different
> @@ -2501,8 +2502,11 @@ __latent_entropy struct task_struct *copy_process(
> mmput(p->mm);
> }
> bad_fork_cleanup_signal:
> - if (!(clone_flags & CLONE_THREAD))
> - free_signal_struct(p->signal);
> + if (!(clone_flags & CLONE_THREAD)) {
> + free_sig = p->signal;
> + p->signal = NULL;
> + free_signal_struct(free_sig);
> + }
> bad_fork_cleanup_sighand:
> __cleanup_sighand(p->sighand);
> bad_fork_cleanup_fs:
> diff --git a/kernel/pid.c b/kernel/pid.c
> index a31771bc89c1..1a012e033552 100644
> --- a/kernel/pid.c
> +++ b/kernel/pid.c
> @@ -329,9 +329,9 @@ EXPORT_SYMBOL_GPL(find_vpid);
>
> static struct pid **task_pid_ptr(struct task_struct *task, enum pid_type type)
> {
> - return (type == PIDTYPE_PID) ?
> - &task->thread_pid :
> - &task->signal->pids[type];
> + if (type == PIDTYPE_PID)
> + return &task->thread_pid;
> + return task->signal ? &task->signal->pids[type] : NULL;
> }
>
> /*
> --
> 2.34.1
>
--
Kees Cook
next parent reply other threads:[~2026-01-07 20:39 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20260105045609.1764387-1-wangqing7171@gmail.com>
2026-01-07 20:39 ` Kees Cook [this message]
2026-01-08 2:15 ` [PATCH] fork/pid: Fix use-after-free in __task_pid_nr_ns Qing Wang
2026-01-08 3:44 ` Qing Wang
2026-01-05 4:36 Qing Wang
2026-01-05 22:46 ` Andrew Morton
2026-01-06 7:07 ` Qing Wang
2026-01-06 9:04 ` Oleg Nesterov
2026-01-06 10:06 ` Qing Wang
2026-01-06 10:26 ` Qing Wang
2026-01-06 10:58 ` Oleg Nesterov
2026-01-06 10:58 ` Qing Wang
2026-01-06 11:19 ` Oleg Nesterov
2026-01-07 2:43 ` Qing Wang
2026-01-06 12:50 ` Oleg Nesterov
2026-01-07 9:40 ` Qing Wang
2026-01-07 14:54 ` Oleg Nesterov
2026-01-07 9:43 ` Oleg Nesterov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=202601071238.F86C2B8@keescook \
--to=kees@kernel.org \
--cc=Liam.Howlett@oracle.com \
--cc=akpm@linux-foundation.org \
--cc=bsegall@google.com \
--cc=david@kernel.org \
--cc=dietmar.eggemann@arm.com \
--cc=juri.lelli@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lorenzo.stoakes@oracle.com \
--cc=mgorman@suse.de \
--cc=mhocko@suse.com \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
--cc=rppt@kernel.org \
--cc=surenb@google.com \
--cc=syzbot+e0378d4f4fe57aa2bdd0@syzkaller.appspotmail.com \
--cc=vbabka@suse.cz \
--cc=vincent.guittot@linaro.org \
--cc=vschneid@redhat.com \
--cc=wangqing7171@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.