Re: [PATCH] firmware: qcom: pas_tee: handle a NULL resource table

[Jorge Ramirez <jorge.ramirez@oss.qualcomm.com>]

On 12/10/26 14:48:22, Sumit Garg wrote:
> Hey Jorge,
> 
> On Mon, Oct 12, 2026 at 1:33 PM Jorge Ramirez
> <jorge.ramirez@oss.qualcomm.com> wrote:
> >
> > On 06/10/26 08:41:49, Jorge Ramirez-Ortiz wrote:
> > > Stopping a remote processor clears its cached resource table pointer
> > > but leaves the size set. On restart, qcom_pas_tee_get_rsc_table() copies
> > > from NULL when the firmware has no resource table:
> > >
> > >   pc : __pi_memcpy_generic+0x110/0x22c
> > >   lr : qcom_pas_tee_get_rsc_table+0xf0/0x244
> > >
> > > Zero the input size when the table is NULL so the copy is skipped.
> > >
> > > Fixes: b6f7978da0c4 ("firmware: qcom: Add a PAS TEE service")
> > > Signed-off-by: Jorge Ramirez-Ortiz <jorge.ramirez@oss.qualcomm.com>
> > > ---
> > >  drivers/firmware/qcom/qcom_pas_tee.c | 5 ++++-
> > >  1 file changed, 4 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/firmware/qcom/qcom_pas_tee.c b/drivers/firmware/qcom/qcom_pas_tee.c
> > > index ac33a00687aa..a52a7df385ff 100644
> > > --- a/drivers/firmware/qcom/qcom_pas_tee.c
> > > +++ b/drivers/firmware/qcom/qcom_pas_tee.c
> > > @@ -230,12 +230,15 @@ static void *qcom_pas_tee_get_rsc_table(struct device *dev,
> > >               },
> > >               [1] = {
> > >                       .attr = TEE_IOCTL_PARAM_ATTR_TYPE_MEMREF_INOUT,
> > > -                     .u.memref.size = input_rt_size,
> > >               }
> > >       };
> > >       void *rt_buf = NULL;
> > >       int ret;
> > >
> > > +     if (!input_rt)
> > > +             input_rt_size = 0;
> > > +     param[1].u.memref.size = input_rt_size;
> > > +
> > >       ret = tee_client_invoke_func(data->ctx, &inv_arg, param);
> > >       if (ret < 0 || inv_arg.ret != 0) {
> > >               dev_err(dev, "PAS get RT failed, pas_id: %d, ret: %d, err: 0x%x\n",
> > > --
> > > 2.54.0
> > >
> >
> > could  we merge this? as mentioned, it  protects against blindly
> > dereferencin a pointer that might be null. I submitted another patch
> > that should address the issue in a higher level interface but regardless
> > I see nothing wrong with catching it here as well.
> >
> 
> I would rather prefer to error out to the caller rather than fixing it
> here. Doesn't tee_client_invoke_func() already error out or it causes
> a kernel panic instead?

it panics

the advantage of having it here as well is that other backend(s) are not
restricted in case they chose to take different actions.

> 
> -Sumit