[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250804-gepfercht-delfin-0172b1ee9556@brauner>
Date: Mon, 4 Aug 2025 14:14:02 +0200
From: Christian Brauner <brauner@...nel.org>
To: Oleg Nesterov <oleg@...hat.com>
Cc: 高翔 <gaoxiang17@...omi.com>,
Al Viro <viro@...iv.linux.org.uk>, Xiang Gao <gxxa03070307@...il.com>,
"mjguzik@...il.com" <mjguzik@...il.com>, "Liam.Howlett@...cle.com" <Liam.Howlett@...cle.com>,
"joel.granados@...nel.org" <joel.granados@...nel.org>, "lorenzo.stoakes@...cle.com" <lorenzo.stoakes@...cle.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] pid: Add a judgment for ns null in pid_nr_ns
On Mon, Aug 04, 2025 at 01:49:01PM +0200, Oleg Nesterov wrote:
> On 08/04, 高翔 wrote:
> >
> > struct task_struct *tsk = current;
> >
> > struct task_struct *parent;
> >
> > ...
> >
> > info->pid = task_pid_vnr(tsk);
> > rcu_read_lock();
> > parent = rcu_dereference(tsk->real_parent);
> > get_task_struct(parent);
> > rcu_read_unlock();
> > info->ppid = task_tgid_vnr(parent);
> > strncpy(info->ptask_name, parent->comm, TASK_COMM_LEN);
> > put_task_struct(parent);
>
> So I guess the kernel crashes when you try to obtain another process's pid, not
> the current process's pid. This is was I suspected.
>
> This code is buggy. tsk->real_parent points to nowhere if tsk = current was reaped.
> rcu_read_lock() alone can't help. Even get_task_struct(parent) is not safe. And it
> is not needed.
>
> You need something like
>
> info->pid = info->ppid = 0;
>
> rcu_read_lock();
> if (pid_alive(tsk)) {
> info->pid = task_pid_vnr(tsk);
> info->ppid = task_tgid_vnr(tsk->real_parent);
> }
> rcu_read_unlock();
I distinctly remember having seen a similar patch about 5 years ago that
did the exact same fix for some out-of-tree abuse:
20201201024811.GA72235@...172-31-62-0.us-west-2.compute.internal
Where in the kernel is that code supposed to live? Is this again an
out-of-tree module?
__task_pid_nr_ns+0x74/0xd0
get_common_info+0x9c/0x1c0 [io_xxx 39b55c95a0fe9416f7d7be396be0fd1d6f590f17]
io_monitor_global_log+0x1a0/0x294 [io_xxx 39b55c95a0fe9416f7d7be396be0fd1d6f590f17]
cb_android_vh_ufs_compl_command+0x304/0x578 [io_xxx 39b55c95a0fe9416f7d7be396be0fd1d6f590f17]
__traceiter_android_vh_ufs_compl_command+0x54/0x78
all looks to me like some out-of-tree stuff...
So no, not taking that.
The only thing I can see as a sensible addition is:
diff --git a/kernel/pid.c b/kernel/pid.c
index c45a28c16cd2..f27cbc208c5e 100644
--- a/kernel/pid.c
+++ b/kernel/pid.c
@@ -491,6 +491,9 @@ pid_t pid_nr_ns(struct pid *pid, struct pid_namespace *ns)
struct upid *upid;
pid_t nr = 0;
+ if (unlikely(WARN_ON_ONCE(!ns)))
+ return 0;
+
if (pid && ns->level <= pid->level) {
upid = &pid->numbers[ns->level];
if (upid->ns == ns)
So that we yell at abusers of pid_nr_ns(). But even that...
Powered by blists - more mailing lists