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 ADA62280332 for ; Wed, 7 Jan 2026 20:39:38 +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=1767818378; cv=none; b=P8CrbpNFW1c6rbmqMFnYLQkSMfHZefpa1Qm7/ph9AGWdv8CKOXr4dUur8fK8oxAcGbr6/FKCYFNDdQZWG1NIPqiGqfzUdf6r6eDk/DJYWAKUZY5VMVG8o1AqpPaCpRL33eKq03Y168YrOx0ldAt2cXmLYy7FW8XSLB582p6h2is= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767818378; c=relaxed/simple; bh=vDWYrFckz07hGf4wxpisLiCyQloyljBsPb6Qu5XUQcI=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=V8j9Eooe8Ki/pPGw69BRGfek5efT2QAi8JFExo2F+uh3C9BFWcUom+AbV5eykbv7A/ojQlZz0xt445RSUqFtyQ0NQ8ZuAh0DwECluF2xwpRxSMnQb71G3QVlhXQ8zWrbdZdinZagOpMQAHT+mGpnkKd/GPKp1C5CG0vyeOJ9etQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=TT3fYyI6; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="TT3fYyI6" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 41064C4CEF1; Wed, 7 Jan 2026 20:39:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1767818378; bh=vDWYrFckz07hGf4wxpisLiCyQloyljBsPb6Qu5XUQcI=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=TT3fYyI6dkO0dUgOHl8gZOPfcOgK8aXYhSHBYCPSUpbC7J87sQKARdVKUwsoKT4wN LMpLjXb5zuw0ynV19JzrLUZX3mDhbNJ9kJzmP6c/EHyWZj7ZyTMSuFJIuG144W4hnq ma1BQmt1VUBXFZ2RrVuGt1vY5jp6qKtXgu+0S+EJ5DJsHJ7qao9t6gnaeaqXdSBLfY gXB4MGpm/S/womHmfGrrTOV8lCwoSMQ7b+ION89CwiV51iQX5eS10cmcTf2McLusZl 064mZRgU6x0gK/1YuaExKOGzUMedanu97zC6opIwkMiHTZPz2cZk5xuJ25A3KCzvO+ os26ohyzPDAqg== Date: Wed, 7 Jan 2026 12:39:37 -0800 From: Kees Cook To: Qing Wang Cc: Andrew Morton , David Hildenbrand , Lorenzo Stoakes , "Liam R . Howlett" , Vlastimil Babka , Mike Rapoport , Suren Baghdasaryan , Michal Hocko , Ingo Molnar , Peter Zijlstra , Juri Lelli , Vincent Guittot , Dietmar Eggemann , Steven Rostedt , Ben Segall , Mel Gorman , Valentin Schneider , 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 Message-ID: <202601071238.F86C2B8@keescook> References: <20260105045609.1764387-1-wangqing7171@gmail.com> 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-Disposition: inline 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 > --- > 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