Re: [PATCH v1 4/4] pinctrl: qcom: hawi-lpass-lpi: add Hawi LPASS LPI TLMM

[sashiko-bot@kernel.org]

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

Pre-existing issues:
- [High] Premature destruction of `pctrl->lock` mutex before pinctrl device unregistration creates a use-after-free window.
--

--- Patch [4]: [PATCH v1 4/4] pinctrl: qcom: hawi-lpass-lpi: add Hawi LPASS LPI TLMM ---
commit 38f7bb1223fcfb1f3a3b0698eedf3998e066c226
Author: Prasad Kumpatla <prasad.kumpatla@oss.qualcomm.com>

pinctrl: qcom: hawi-lpass-lpi: add Hawi LPASS LPI TLMM

This commit adds a new pin controller driver for the Low Power Audio
SubSystem (LPASS) Low Power Island (LPI) of the Qualcomm Hawi SoC. It
supports 23 GPIOs with various alternate functions and includes a custom
pingroup macro to handle test_bus mux slot offsets.

> diff --git a/drivers/pinctrl/qcom/pinctrl-hawi-lpass-lpi.c b/drivers/pinctrl/qcom/pinctrl-hawi-lpass-lpi.c
> new file mode 100644
> index 0000000000000..7036bf4c66920
> --- /dev/null
> +++ b/drivers/pinctrl/qcom/pinctrl-hawi-lpass-lpi.c
[ ... ]
> +static struct platform_driver lpi_pinctrl_driver = {
> +	.driver = {
> +		.name = "qcom-hawi-lpass-lpi-pinctrl",
> +		.of_match_table = lpi_pinctrl_of_match,
> +		.pm = pm_ptr(&lpi_pinctrl_pm_ops),
> +	},
> +	.probe = lpi_pinctrl_probe,
> +	.remove = lpi_pinctrl_remove,

[Severity: High]
This isn't a bug introduced by this patch, but does the core driver destroy
the mutex while the pinctrl device is still registered?

Looking at the core driver drivers/pinctrl/qcom/pinctrl-lpass-lpi.c:

drivers/pinctrl/qcom/pinctrl-lpass-lpi.c:lpi_pinctrl_remove() {
	struct lpi_pinctrl *pctrl = platform_get_drvdata(pdev);
	int i;

	mutex_destroy(&pctrl->lock);

	for (i = 0; i < pctrl->data->npins; i++)
		pinctrl_generic_remove_group(pctrl->ctrl, i);
}

The core driver uses devm_pinctrl_register() to register the pinctrl device,
which ties its unregistration to the devres teardown phase that occurs after
lpi_pinctrl_remove() returns.

Could this create a window where the pinctrl device is still fully registered
and visible to the system, but its lock is destroyed? If an unprivileged
local user reads pinctrl debugfs while the device unbinds, could this
trigger a kernel panic or oops by operating on a destroyed mutex?

The same pattern also appears in the err_pinctrl path of lpi_pinctrl_probe():

drivers/pinctrl/qcom/pinctrl-lpass-lpi.c:lpi_pinctrl_probe() {
    ...
err_pinctrl:
	mutex_destroy(&pctrl->lock);

	return ret;
}

Here, the mutex is destroyed in the error path while the devm-registered
pinctrl device is still live globally until devres unregisters it.

> +};
> +
> +module_platform_driver(lpi_pinctrl_driver);

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260708114924.1069239-1-prasad.kumpatla@oss.qualcomm.com?part=4