Re: [PATCH v4 05/10] dmaengine: qcom: gpi: Use bus width capability helpers

[sashiko-bot@kernel.org]

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

Pre-existing issues:
- [High] Missing cleanup for DMA controller and async device registration in error paths and missing .remove method lead to UAF.
--

commit bbcb7726e80023f035efafba93cea9b1b9a4a1c3
Author: Nuno Sá <nuno.sa@analog.com>

dmaengine: qcom: gpi: Use bus width capability helpers

This commit uses the new dma_bus_width_set helper to advertise supported
bus widths, replacing legacy assignments.

> diff --git a/drivers/dma/qcom/gpi.c b/drivers/dma/qcom/gpi.c
> index a5055a6273af6..3a35bf4c33978 100644
> --- a/drivers/dma/qcom/gpi.c
> +++ b/drivers/dma/qcom/gpi.c

[ ... ]

> @@ -2265,8 +2266,15 @@ static int gpi_probe(struct platform_device *pdev)
>  	/* configure dmaengine apis */
>  	gpi_dev->dma_device.directions = BIT(DMA_DEV_TO_MEM) | BIT(DMA_MEM_TO_DEV);
>  	gpi_dev->dma_device.residue_granularity = DMA_RESIDUE_GRANULARITY_DESCRIPTOR;
> -	gpi_dev->dma_device.src_addr_widths = DMA_SLAVE_BUSWIDTH_8_BYTES;
> -	gpi_dev->dma_device.dst_addr_widths = DMA_SLAVE_BUSWIDTH_8_BYTES;
> +	ret = dma_bus_width_set(gpi_dev->dma_device.src_bus_widths,
> +				DMA_SLAVE_BUSWIDTH_8_BYTES);
> +	if (ret)
> +		return ret;
> +
> +	ret = dma_bus_width_set(gpi_dev->dma_device.dst_bus_widths,
> +				DMA_SLAVE_BUSWIDTH_8_BYTES);
> +	if (ret)
> +		return ret;

[Severity: High]
This is a pre-existing issue, but while looking at the changes in
gpi_probe, I noticed a potential memory corruption issue on the error
path and during driver unbind.

If of_dma_controller_register fails later in gpi_probe, it returns an
error without unregistering the previously registered async DMA device:

gpi_probe() {
    ...
    ret = dma_async_device_register(&gpi_dev->dma_device);
    if (ret) {
        dev_err(gpi_dev->dev, "async_device_register failed ret:%d", ret);
        return ret;
    }

    ret = of_dma_controller_register(gpi_dev->dev->of_node,
                                     gpi_of_dma_xlate, gpi_dev);
    if (ret) {
        dev_err(gpi_dev->dev, "of_dma_controller_reg failed ret:%d", ret);
        return ret;
    }
    ...
}

Additionally, the platform driver gpi_driver completely lacks a remove
callback. If the driver is manually unbound via sysfs, devres will free
the driver's memory while leaving the DMA device and OF controller globally
registered.

Could this lead to a use-after-free if the dangling dma_device pointer is
accessed by other subsystems? Should the error path and driver teardown
clean up these registrations?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260911-dmaengine-support-wider-dma-masks-v4-0-72b8fd4cc78e@analog.com?part=5