Re: [PATCH] dmaengine: mv_xor: return descriptor to free pool on io_win failure

[sashiko-bot@kernel.org]

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

Pre-existing issues:
- [High] Concurrent access to shared MBUS window configuration in `mv_xor_add_io_win` without synchronization leads to arbitrary DMA memory corruption.
- [High] Missing `tasklet_kill()` during channel removal leads to Use-After-Free.
- [High] `free_irq()` is called after freeing DMA descriptors, risking Use-After-Free in the interrupt handler.
--

commit 8b478eae94fa4a954430bcc670fc167e9a399a15
Author: Rosen Penev <rosenp@gmail.com>

dmaengine: mv_xor: return descriptor to free pool on io_win failure

When mv_xor_prep_dma_xor() allocates a descriptor slot and then
mv_xor_add_io_win() fails in the source-address loop, the slot
stays on the allocated list and is never reclaimed. This returns
the slot to the free pool under the channel lock before returning
NULL on failure.

> diff --git a/drivers/dma/mv_xor.c b/drivers/dma/mv_xor.c
> index 25ed61f1b0899..dd4f150d5fb12 100644
> --- a/drivers/dma/mv_xor.c
> +++ b/drivers/dma/mv_xor.c
> @@ -583,8 +583,13 @@ mv_xor_prep_dma_xor(struct dma_chan *chan, dma_addr_t dest, dma_addr_t *src,
>  		while (src_cnt--) {
>  			/* Check if a new window needs to get added for 'src' */
>  			ret = mv_xor_add_io_win(mv_chan, src[src_cnt]);

[Severity: High]
This isn't a bug introduced by this patch, but can this concurrent access
corrupt the MBUS window mappings?

mv_xor_prep_dma_xor() is called concurrently on multiple channels sharing the
same XOR device. It calls mv_xor_add_io_win() which performs an unprotected
read:

	win_enable = readl(base + WINDOW_BAR_ENABLE(0));

It then modifies the shared device-level window cache:

	xordev->win_start[i] = addr;
	xordev->win_end[i] = addr + size;

And writes the clobbered value back to the hardware:

	writel(win_enable, base + WINDOW_BAR_ENABLE(0));

Since this lacks synchronization across channels, could this race condition
lead to the DMA engine accessing incorrect physical addresses?

> -			if (ret)
> +			if (ret) {
> +				spin_lock_bh(&mv_chan->lock);
> +				list_move_tail(&sw_desc->node,
> +					       &mv_chan->free_slots);
> +				spin_unlock_bh(&mv_chan->lock);
>  				return NULL;
> +			}
>  			mv_desc_set_src_addr(sw_desc, src_cnt, src[src_cnt]);
>  		}
>  	}

[Severity: High]
This is a pre-existing issue, but does the channel teardown leak the pending
background execution context?

Looking at mv_xor_channel_remove(), it frees the interrupt handler and DMA
device but neglects to call tasklet_kill(&mv_chan->irq_tasklet):

static int mv_xor_channel_remove(struct mv_xor_chan *mv_chan)
{
	struct dma_chan *chan, *_chan;
	[ ... ]

Since free_irq() does not wait for tasklets to finish, can a pending tasklet
execute asynchronously after mv_xor_channel_remove() returns and devres has
freed the mv_chan memory, resulting in a use-after-free?


[Severity: High]
This is a pre-existing issue, but does the teardown order risk a
use-after-free in the interrupt handler?

In mv_xor_channel_remove(), the DMA memory used by the hardware and IRQ
handler is freed here:

	dma_free_wc(dev, MV_XOR_POOL_SIZE,
			  mv_chan->dma_desc_pool_virt, mv_chan->dma_desc_pool);

The interrupt handler is freed later:

	free_irq(mv_chan->irq, mv_chan);

If a hardware interrupt fires between these two calls, or is already running
on another CPU, wouldn't it trigger the interrupt handler and subsequently
schedule the tasklet? 

This would access the already-freed descriptor memory
(mv_chan->dma_desc_pool_virt). Should the teardown order disable and free
IRQs before freeing the resources the IRQ handler relies on?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260909234924.103418-1-rosenp@gmail.com?part=1