Re: [PATCH v3 3/6] firmware: qcom: scm: Add support for setting Bluetooth power modes

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Critical] Command ID collision in TrustZone SMC calls causing potential physical memory corruption
--

commit 26b3bd594fb013254f8ba044e310cbb49348c961
Author: George Moussalem <george.moussalem@outlook.com>

firmware: qcom: scm: Add support for setting Bluetooth power modes

This commit adds support for configuring the Bluetooth subsystem power modes
on IPQ5018 through a new Secure Channel Manager call. It includes an
availability check to ensure the call is supported by the QSEE image.

> diff --git a/drivers/firmware/qcom/qcom_scm.h b/drivers/firmware/qcom/qcom_scm.h
> index caab80a73e17f..5579df5a2aca7 100644
> --- a/drivers/firmware/qcom/qcom_scm.h
> +++ b/drivers/firmware/qcom/qcom_scm.h
> @@ -105,6 +105,7 @@ int qcom_scm_shm_bridge_enable(struct device *scm_dev);
>  #define QCOM_SCM_PIL_PAS_SHUTDOWN	0x06
>  #define QCOM_SCM_PIL_PAS_IS_SUPPORTED	0x07
>  #define QCOM_SCM_PIL_PAS_MSS_RESET	0x0a
> +#define QCOM_SCM_PIL_PAS_BT_PWR_MODE	0x21
>  #define QCOM_SCM_PIL_PAS_GET_RSCTABLE	0x21

[Severity: Critical]
Does this new macro collide with the existing QCOM_SCM_PIL_PAS_GET_RSCTABLE
command? Both are defined as 0x21 within the QCOM_SCM_SVC_PIL service.

Because GET_RSCTABLE is widely supported on Qualcomm platforms, the
availability check in qcom_scm_pas_set_bluetooth_power_mode() will pass
even if the firmware does not actually support the new Bluetooth power mode
command:

drivers/firmware/qcom/qcom_scm.c:qcom_scm_pas_set_bluetooth_power_mode() {
    ...
    if (!__qcom_scm_is_call_available(__scm->dev, QCOM_SCM_SVC_PIL,
                                      QCOM_SCM_PIL_PAS_BT_PWR_MODE))
        return -EOPNOTSUPP;
    ...
}

When the SMC call is subsequently issued with only 2 arguments, TrustZone's
GET_RSCTABLE handler will receive the call but expect 5 arguments. Could
this cause TrustZone to treat the uninitialized remaining arguments as
physical addresses, resulting in an attempt to write the resource table to
physical address 0x0?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260703-ipq5018-bluetooth-v3-0-62da72818ab3@outlook.com?part=3