Re: [PATCH v3 04/13] dmaengine: dw-edma: Initialize IRQ data before requesting IRQs

[sashiko-bot@kernel.org]

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

Pre-existing issues:
- [High] The `dw_edma_device_terminate_all()` function fails to immediately halt the DMA hardware, leading to memory corruption or IOMMU faults when clients subsequently unmap and free DMA memory.
--

commit e17b2c11b8213371ac3e2d7a92dfd8d2c53290ea
Author: Koichiro Den <den@valinux.co.jp>

dmaengine: dw-edma: Initialize IRQ data before requesting IRQs

This patch fixes a potential NULL pointer dereference in the dw-edma driver
by setting the dw back pointer in struct dw_edma_irq before installing
the IRQ handlers. This ensures the pointer is valid if a shared interrupt
triggers immediately after request_irq().

> diff --git a/drivers/dma/dw-edma/dw-edma-core.c b/drivers/dma/dw-edma/dw-edma-core.c
> index ca0504eac1fca..c782eaa12021e 100644
> --- a/drivers/dma/dw-edma/dw-edma-core.c
> +++ b/drivers/dma/dw-edma/dw-edma-core.c
> @@ -943,7 +943,6 @@ static int dw_edma_channel_setup(struct dw_edma *dw, u32 wr_alloc, u32 rd_alloc)
>  		else
>  			irq->rd_mask |= BIT(chan->id);
>  
> -		irq->dw = dw;

[Severity: High]
This is a pre-existing issue, but does dw_edma_device_terminate_all() fail
to immediately halt the DMA hardware?

drivers/dma/dw-edma/dw-edma-core.c:dw_edma_device_terminate_all() {
    ...
	} else {
		chan->request = EDMA_REQ_STOP;
	}

	return err;
}

The dmaengine_terminate_sync() API mandates that a DMA channel is
synchronously stopped, or that the driver implements device_synchronize to
wait for completion.

However, dw_edma_device_terminate_all() sets chan->request = EDMA_REQ_STOP
and returns 0 without writing to the hardware to halt the transfer or
implementing device_synchronize.

If the DMA engine client assumes the channel is stopped, might it proceed
to unmap and free the DMA memory while the DMA hardware continues to read
or write to this unmapped physical memory?

Could this lead to use-after-free and memory corruption or IOMMU faults?

[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260620170040.3756043-1-den@valinux.co.jp?part=4