Re: [PATCH v2 03/12] arm64: dts: imx8qm-mek: fix dsp reserved memory node names for remoteproc

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

Pre-existing issues:
- [High] Missing cancellation of `rproc_work` leads to Use-After-Free on driver unbind.
--

--- Patch [3]: [PATCH v2 03/12] arm64: dts: imx8qm-mek: fix dsp reserved memory node names for remoteproc ---
commit ccca82516c9f0cb91d5a0dd4d02b6d18ce2a6c7e
Author: Peng Fan <[email protected]>

arm64: dts: imx8qm-mek: fix dsp reserved memory node names for remoteproc

The imx_dsp_rproc driver checks for the name "vdev0buffer" to skip
mapping the vdev buffer region, as it is handled by
rproc_add_virtio_dev. With the node named "memory", the check fails
and the region gets unnecessarily mapped.

Rename the DSP reserved memory nodes to use proper names for
consistency with other remoteproc reserved memory regions and to
ensure the vdev0buffer check works correctly.

Rename the DSP reserved memory nodes to use the expected names so
the driver can correctly identify and handle each region.

Fixes: d0ee7ae8ce26 ("arm64: dts: imx8qm-mek: enable dsp node for rproc usage")
Signed-off-by: Peng Fan <[email protected]>

> diff --git a/arch/arm64/boot/dts/freescale/imx8qm-mek.dts b/arch/arm64/boot/dts/freescale/imx8qm-mek.dts
> index 8b67fb5d670da..1afa65bd955ec 100644
> --- a/arch/arm64/boot/dts/freescale/imx8qm-mek.dts
> +++ b/arch/arm64/boot/dts/freescale/imx8qm-mek.dts
[ ... ]
> -		dsp_vdev0buffer: memory@94300000 {
> +		dsp_vdev0buffer: vdev0buffer@94300000 {
>  			compatible = "shared-dma-pool";
>  			reg = <0 0x94300000 0 0x100000>;
>  			no-map;

[Severity: High]
This isn't a bug introduced by this patch, but is there a missing cancellation
of rproc_work in the imx_dsp_rproc driver that could lead to a use-after-free
on driver unbind?

In drivers/remoteproc/imx_dsp_rproc.c:imx_dsp_rproc_probe():

	INIT_WORK(&priv->rproc_work, imx_dsp_rproc_vq_work);

And later in imx_dsp_rproc_rx_tx_callback(), the work is scheduled:

	default:
		schedule_work(&priv->rproc_work);
		break;

Because the driver does not define a remove callback and relies entirely on
devres cleanup, the work is never explicitly cancelled (e.g., via
cancel_work_sync()).

During driver unbind, devm_rproc_alloc teardown will free the rproc structure,
along with its embedded priv. If the scheduled work executes concurrently or is
pending on the system workqueue, it will access the freed priv->rproc, leading
to a use-after-free.

Could a devres action be added to properly flush and destroy this workqueue
before the rproc is freed?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=3