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

Message-Id: <20260105043627.1758935-1-wangqing7171@gmail.com>
Date: Mon,  5 Jan 2026 12:36:27 +0800
From: Qing Wang <wangqing7171@...il.com>
To: mingo@...hat.com,
	peterz@...radead.org,
	juri.lelli@...hat.com,
	vincent.guittot@...aro.org,
	akpm@...ux-foundation.org,
	david@...nel.org
Cc: 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,
	oleg@...hat.com,
	mjguzik@...il.com,
	jack@...e.cz,
	joel.granados@...nel.org,
	linux-kernel@...r.kernel.org,
	Qing Wang <wangqing7171@...il.com>,
	syzbot+e0378d4f4fe57aa2bdd0@...kaller.appspotmail.com
Subject: [PATCH] fork/pid: Fix use-after-free in __task_pid_nr_ns

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.

Reported-by: syzbot+e0378d4f4fe57aa2bdd0@...kaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=e0378d4f4fe57aa2bdd0
Signed-off-by: Qing Wang <wangqing7171@...il.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