Re: [PATCH v7 11/15] media: qcom: Pass proper PAS ID to set_remote_state API

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] Lockless access and TOCTOU (Time-Of-Check to Time-Of-Use) race on the global `ops_ptr` variable leading to a NULL pointer dereference.
--

commit cea57543db0155e85cd736ed70440a251d359393
Author: Sumit Garg <sumit.garg@oss.qualcomm.com>

media: qcom: Pass proper PAS ID to set_remote_state API
    
This commit updates the SCM backend calls in the iris and venus drivers
to pass the correct PAS ID to qcom_pas_set_remote_state() instead of 0,
which is used by OP-TEE for bookkeeping purposes.

> diff --git a/drivers/media/platform/qcom/iris/iris_firmware.c b/drivers/media/platform/qcom/iris/iris_firmware.c
> index b3c5281aea919..856fa6a79064c 100644
> --- a/drivers/media/platform/qcom/iris/iris_firmware.c
> +++ b/drivers/media/platform/qcom/iris/iris_firmware.c
> @@ -109,5 +109,5 @@ int iris_fw_unload(struct iris_core *core)
>  
>  int iris_set_hw_state(struct iris_core *core, bool resume)
>  {
> -	return qcom_pas_set_remote_state(resume, 0);
> +	return qcom_pas_set_remote_state(resume, core->iris_platform_data->pas_id);

[Severity: High]
This isn't a bug introduced by this patch, but since this code relies on the
underlying qcom_pas_set_remote_state() function, is there a race condition
in how ops_ptr is accessed?

Looking at qcom_pas_set_remote_state() in drivers/firmware/qcom/qcom_pas.c:

int qcom_pas_set_remote_state(u32 state, u32 pas_id)
{
	if (!ops_ptr)
		return -ENODEV;

	return ops_ptr->set_remote_state(ops_ptr->dev, state, pas_id);
}

If the provider driver is concurrently unbound (e.g., via qcom_pas_tee_remove)
or shut down, and qcom_pas_ops_unregister() sets ops_ptr = NULL, could ops_ptr
become NULL between the check and the dereference?

Since there appears to be no locking, RCU, or module reference counting
protecting ops_ptr, could this lead to a NULL pointer dereference, or an
invalid memory access if the provider module is unloaded and the memory
containing the callbacks is freed?

>  }

[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260522115936.201208-1-sumit.garg@kernel.org?part=11