Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <20230713071713.5762-1-xuewen.yan@unisoc.com> <20230725-hemmschwelle-braten-481527898001@brauner>
 <CAB8ipk9CXWmUg13gEHDECXf3DDUvbYyA0y2yFXUuGsAjMSXv8w@mail.gmail.com>
 <20230725-gespeichert-auffuhr-00ed9e57ec7f@brauner> <CAB8ipk_AhvZxoa410F8s=SfLsqCNp+rRi6YgFzdLO7wh+N4KMA@mail.gmail.com>
 <20230726-tierisch-soweit-7bcefe6957dc@brauner>
In-Reply-To: <20230726-tierisch-soweit-7bcefe6957dc@brauner>
From:   Xuewen Yan <xuewen.yan94@gmail.com>
Date:   Thu, 27 Jul 2023 09:21:48 +0800
Message-ID: <CAB8ipk93n-0x7bs4nrQUrsswt81f4e6dHAFpEchc4G3mPKQSjQ@mail.gmail.com>
Subject: Re: [PATCH] pid: Add the judgment of whether ns is NULL in the find_pid_ns
To:     Christian Brauner <brauner@kernel.org>
Cc:     Xuewen Yan <xuewen.yan@unisoc.com>, jack@suse.cz,
        keescook@chromium.org, peterz@infradead.org,
        vincent.guittot@linaro.org, linux-kernel@vger.kernel.org,
        di.shen@unisoc.com
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On Wed, Jul 26, 2023 at 5:25=E2=80=AFPM Christian Brauner <brauner@kernel.o=
rg> wrote:
>
> On Wed, Jul 26, 2023 at 09:23:13AM +0800, Xuewen Yan wrote:
> > On Tue, Jul 25, 2023 at 8:47=E2=80=AFPM Christian Brauner <brauner@kern=
el.org> wrote:
> > >
> > > On Tue, Jul 25, 2023 at 08:24:18PM +0800, Xuewen Yan wrote:
> > > > On Tue, Jul 25, 2023 at 4:49=E2=80=AFPM Christian Brauner <brauner@=
kernel.org> wrote:
> > > > >
> > > > > On Thu, Jul 13, 2023 at 03:17:13PM +0800, Xuewen Yan wrote:
> > > > > > There is no the judgment of whether namspace is NULL in find_pi=
d_ns.
> > > > > > But there is a corner case when ns is null, for example: if use=
r
> > > > > > call find_get_pid when current is in exiting, the following sta=
ck would
> > > > > > set thread_id be null:
> > > > > > release_task
> > > > > >     __exit_signal(p);
> > > > > >         __unhash_process(tsk, group_dead);
> > > > > >               detach_pid(p, PIDTYPE_PID);
> > > > > >                   __change_pid(task, type, NULL);
> > > > > >
> > > > > > If user call find_get_pid at now, in find_vpid function, the
> > > > >
> > > > > I fail to see how this can happen. The code you're referencing is=
 in
> > > > > release_task(). If current has gone through that then current obv=
iously
> > > > > can't call find_vpid() on itself anymore or anything else for tha=
t
> > > > > matter.
> > > >
> > > > This happened when user calls  find_vpid() in irq.
> > > >
> > > > [72117.635162] Call trace:
> > > > [72117.635595]  idr_find+0xc/0x24
> > > > [72117.636103]  find_get_pid+0x40/0x68
> > > > [72117.636812]  send_event+0x88/0x180 [demux]
> > > > [72117.637593]  vbvop_copy_data+0x150/0x344 [demux]
> > > > [72117.638434]  dmisr_video_parsing_mpeg12+0x29c/0x42c [demux]
> > > > [72117.639393]  dmisr_video_parsing_switch+0x68/0xec [demux]
> > > > [72117.640332]  dmisr_handle_video_pes+0x10c/0x26c [demux]
> > > > [72117.641108]  tasklet_action_common+0x130/0x224
> > > > [72117.641784]  tasklet_action+0x28/0x34
> > > > [72117.642366]  __do_softirq+0x128/0x4dc
> > > > [72117.642944]  irq_exit+0xf8/0xfc
> > > > [72117.643459]  __handle_domain_irq+0xb0/0x108
> > > > [72117.644102]  gic_handle_irq+0x6c/0x124
> > > > [72117.644691]  el1_irq+0x108/0x200
> > > > [72117.645217]  _raw_write_unlock_irq+0x2c/0x5c
> > > > [72117.645870]  release_task+0x144/0x1ac   <<<<<<
> > > > [72117.646447]  do_exit+0x524/0x94c
> > > > [72117.646970]  __do_sys_exit_group+0x0/0x14
> > > > [72117.647591]  do_group_exit+0x0/0xa0
> > > > [72117.648146]  __se_sys_exit+0x0/0x20
> > > > [72117.648704]  el0_svc_common+0xcc/0x1bc
> > > > [72117.649292]  el0_svc_handler+0x2c/0x3c
> > > > [72117.649881]  el0_svc+0x8/0xc
> > > >
> > > > In release_task, write_unlock_irq(&tasklist_lock) will open irq, at
> > > > this time, if user calls find_get_pid() in irq, because
> > > > current->thread_id is NULL,
> > > > it will handle the NULL pointer.
> > >
> > > Uhm, where is that code from? This doesn't seem to be upstream.
> >
> > It's from our own platform, we found someone called  find_get_pid() in
> > the module, and caused the crash.
>
> So this is a bug report for an out of tree driver which I'm sure you're
> aware we consider mostly irrelevant unless this is an upstream issue.
>
> Please work around or better fix this in your out of tree driver or
> please show a reproducer how this can happen on upstream kernels.
>
> Otherwise I don't see why we'd care.

Okay, Thanks a lot!

BR