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: <20221109141701.237407-1-zyytlz.wz@163.com> <20221109223257.GB34247@hpe.com>
In-Reply-To: <20221109223257.GB34247@hpe.com>
From:   Zheng Hacker <hackerzheng666@gmail.com>
Date:   Thu, 10 Nov 2022 11:24:45 +0800
Message-ID: <CAJedcCzB3-iuWU0jdDQ0C5m6mZBD4p7DW8=gYkE7LjTfg=cFZg@mail.gmail.com>
Subject: Re: [PATCH v9] misc: sgi-gru: fix use-after-free error in
 gru_set_context_option, gru_fault and gru_handle_user_call_os
To:     Dimitri Sivanich <sivanich@hpe.com>
Cc:     Zheng Wang <zyytlz.wz@163.com>, gregkh@linuxfoundation.org,
        zhengyejian1@huawei.com, dimitri.sivanich@hpe.com, arnd@arndb.de,
        linux-kernel@vger.kernel.org, alex000young@gmail.com,
        security@kernel.org, lkp@intel.com
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

Dimitri Sivanich <sivanich@hpe.com> =E4=BA=8E2022=E5=B9=B411=E6=9C=8810=E6=
=97=A5=E5=91=A8=E5=9B=9B 06:33=E5=86=99=E9=81=93=EF=BC=9A
>

> > diff --git a/drivers/misc/sgi-gru/grufault.c b/drivers/misc/sgi-gru/gru=
fault.c
> > index d7ef61e602ed..bdd515d33225 100644
> > --- a/drivers/misc/sgi-gru/grufault.c
> > +++ b/drivers/misc/sgi-gru/grufault.c
> > @@ -656,7 +656,9 @@ int gru_handle_user_call_os(unsigned long cb)
> >       if (ucbnum >=3D gts->ts_cbr_au_count * GRU_CBR_AU_SIZE)
> >               goto exit;
> >
> > -     gru_check_context_placement(gts);
> > +     ret =3D gru_check_context_placement(gts);
>
> Below we do not want to skip over the rest of the logic in either return =
case.
> You will have to do the gru_find_lock_gts again after unloading the gru c=
ontext,
> then check the gts value, then return EINVAL if not set (same as earlier =
in the
> function).

Hello my friend! Thanks for your detailed review. I think you are right.
I'll see what I can do and make a revision.

>
> > +     if (ret)
> > +             goto err;
> >
> >       /*
> >        * CCH may contain stale data if ts_force_cch_reload is set.
> > @@ -677,6 +679,10 @@ int gru_handle_user_call_os(unsigned long cb)
> >  exit:
> >       gru_unlock_gts(gts);
> >       return ret;
> > +err:
> > +     gru_unlock_gts(gts);
> > +     gru_unload_context(gts, 1);
> > +     return -EINVAL;
> >  }
> >
> >  /*
> > @@ -874,7 +880,11 @@ int gru_set_context_option(unsigned long arg)
> >               } else {
> >                       gts->ts_user_blade_id =3D req.val1;
> >                       gts->ts_user_chiplet_id =3D req.val0;
> > -                     gru_check_context_placement(gts);
> > +                     if (gru_check_context_placement(gts)) {
> > +                             gru_unlock_gts(gts);
> > +                             gru_unload_context(gts, 1);
>
> Looking at this again, I think we should return 0, as we originally would
> have done in this case anyway.

I think here we have finished the handling of the gts when it's illegal.
So return 0 is fine for me.

>
> > +                             return -EINVAL;
> > +                     }
> >               }
> >               break;
> >       case sco_gseg_owner:

> >        * If the current task is the context owner, verify that the
> > @@ -726,15 +727,23 @@ void gru_check_context_placement(struct gru_threa=
d_state *gts)
> >        * references. Pthread apps use non-owner references to the CBRs.
> >        */
> >       gru =3D gts->ts_gru;
> > +     /*
> > +      * If gru or gts->ts_tgid_owner isn't initialized properly, retur=
n
> > +      * success is fine, for it's not a deadly error. The related vari=
able
> > +      * can be reconfigure in other function.The caller is responsible
> > +      * for their inspection, and reinitialization if needed.
> > +      */
>
> How about this instead?
>   "If gru or gts->ts_tgid_owner isn't initialized properly, return
>    success to indicate that the caller does not need to unload the gru
>    context.  The caller is responsible for their inspection and
>    reinitialization if needed."
>

Yes, sounds much more clear for the developer, thanks for your suggestion :=
)

Best regards,
Zheng Wang