From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 0390C4C81 for ; Mon, 5 Jan 2026 22:46:42 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767653203; cv=none; b=M7MNKPOGNoIbgt8uBMeRiqZKpdnfQAUEnXV7jTOSn2SK6yDqHKooj2A0sLPZxhvZ/+gfbQVGMXis+pJlBxEhi42Ax0eaHyBvZ/t5x6nLG8r/bR7ds70oeYADwXXSzBvKBr95lfOJAtStOWCLx5QP9m3DdfKsgyIUIjD9UdrlvIM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767653203; c=relaxed/simple; bh=7xYHVihmuTnMNmlfWgzkcck8QgcZsTjPvtMld7g6drA=; h=Date:From:To:Cc:Subject:Message-Id:In-Reply-To:References: Mime-Version:Content-Type; b=fvixvQNQQNKCE8RfcaDPxYMuO2KRr+My2mPRImv2i+wF/9y9j0K20wNN4L90kgx7mkMlP6RNy1dJllrmp11ijH7pO8x6HilTaQg/UK44nrR9IJsoRKOhX0MYpO0Vcdiz1FE0X5bKvpuOXdnSCUK/ubN9HMwKnE8jYpwQVRcBI8c= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b=Lnq2NFqi; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b="Lnq2NFqi" Received: by smtp.kernel.org (Postfix) with ESMTPSA id D77FCC116D0; Mon, 5 Jan 2026 22:46:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1767653202; bh=7xYHVihmuTnMNmlfWgzkcck8QgcZsTjPvtMld7g6drA=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=Lnq2NFqimCBg+8yEKpU9YcKD70bMhih/j8jsbAqjc2vb0gb+2ucAEVxeeMMvCMm+2 YCxqjjxZnl6Et/QUU8+dysJzpF5fG89HwaDtB5DZEvnePOyzJpzEodAFs316LWjZmo xB3dlNq7E6Z6EqRhDZ/bFmpknTizKsXaGfzrVwNE= Date: Mon, 5 Jan 2026 14:46:41 -0800 From: Andrew Morton To: Qing Wang Cc: mingo@redhat.com, peterz@infradead.org, juri.lelli@redhat.com, vincent.guittot@linaro.org, david@kernel.org, dietmar.eggemann@arm.com, rostedt@goodmis.org, bsegall@google.com, lorenzo.stoakes@oracle.com, Liam.Howlett@oracle.com, vbabka@suse.cz, rppt@kernel.org, brauner@kernel.org, oleg@redhat.com, mjguzik@gmail.com, jack@suse.cz, joel.granados@kernel.org, linux-kernel@vger.kernel.org, syzbot+e0378d4f4fe57aa2bdd0@syzkaller.appspotmail.com, Kees Cook Subject: Re: [PATCH] fork/pid: Fix use-after-free in __task_pid_nr_ns Message-Id: <20260105144641.5dcce6cdeac8514580d3cd14@linux-foundation.org> In-Reply-To: <20260105043627.1758935-1-wangqing7171@gmail.com> References: <20260105043627.1758935-1-wangqing7171@gmail.com> X-Mailer: Sylpheed 3.8.0beta1 (GTK+ 2.24.33; x86_64-pc-linux-gnu) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Mon, 5 Jan 2026 12:36:27 +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. Thanks. > > --- 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; > } It might be helpful to have a comment here telling readers how task->signal can be zero. Also, what in here prevents task->signal from being zeroed after we've tested it and before we dereference it?