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

From: Sumit Garg

Date: Mon Oct 12 2026 - 06:55:56 EST


On Mon, Oct 12, 2026 at 3:27 PM Jorge Ramirez
<jorge.ramirez@xxxxxxxxxxxxxxxx> wrote:
>
> 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@xxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxx>
> > > > ---
> > > > 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.
>

Ah I see, feel free to add:

Reviewed-by: Sumit Garg <sumit.garg@xxxxxxxxxxxxxxxx>

Bjorn,

Since this is fixing a kernel panic, is there any chance you can get
this fix in for the v7.3 release?

-Sumit