Re: [PATCH 1/2] dmaengine: dw-axi-dmac: Fix AXI burst length encoding

[sashiko-bot@kernel.org]

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

Pre-existing issues:
- [High] The error handling path for descriptor allocation failures calls `dma_pool_free` with NULL pointers and underflows the `descs_allocated` counter.
- [High] Missing validation of transfer lengths (`len`, `buf_len`, `period_len`) in DMA prep functions leads to division-by-zero panics and out-of-bounds array accesses.
--

commit 1edc02c6412e562b16e650ad23de4b1395cbcb68
Author: Jia Wang <wangjia@ultrarisc.com>

dmaengine: dw-axi-dmac: Fix AXI burst length encoding

The snps,axi-max-burst-len property describes the number of beats in an
AXI burst, while the ARLEN and AWLEN fields encode that value minus one.

The driver keeps axi_rw_burst_len as the actual burst length so that
dma_device.max_burst reports the correct value. However, it also programs
that unencoded value directly into the hardware fields. A value of 256
therefore overflows the 8-bit fields and can cause AXI decode errors.

Subtract one only when constructing hardware descriptors, while keeping
the actual value for dma_device.max_burst.

> diff --git a/drivers/dma/dw-axi-dmac/dw-axi-dmac-platform.c b/drivers/dma/dw-axi-dmac/dw-axi-dmac-platform.c
> index eebed2474210d..742e08cfab435 100644
> --- a/drivers/dma/dw-axi-dmac/dw-axi-dmac-platform.c
> +++ b/drivers/dma/dw-axi-dmac/dw-axi-dmac-platform.c

[ ... ]

> @@ -975,7 +975,7 @@ dma_chan_prep_dma_memcpy(struct dma_chan *dchan, dma_addr_t dst_adr,
>  
>  		reg = CH_CTL_H_LLI_VALID;
>  		if (chan->chip->dw->hdata->restrict_axi_burst_len) {
> -			u32 burst_len = chan->chip->dw->hdata->axi_rw_burst_len;
> +			u32 burst_len = chan->chip->dw->hdata->axi_rw_burst_len - 1;

[Severity: High]
This is a pre-existing issue, but does the error handling in this
function cause a kernel panic if descriptor allocation fails?

If axi_desc_get() fails to allocate a descriptor (e.g., due to memory
exhaustion), the code jumps to err_desc_get and calls axi_desc_put(desc):

	hw_desc->lli = axi_desc_get(chan, &hw_desc->llp);
	if (unlikely(!hw_desc->lli))
		goto err_desc_get;

axi_desc_put() unconditionally loops over all requested descriptors and calls
dma_pool_free() with hw_desc->lli. For elements that were not successfully
allocated, hw_desc->lli is NULL, which causes dma_pool_free() to dereference
a NULL pointer.

Additionally, axi_desc_put() subtracts the full requested number of
descriptors from chan->descs_allocated instead of the successfully allocated
count, which could underflow the counter:

	atomic_sub(descs_put, &chan->descs_allocated);

[Severity: High]
This is also a pre-existing issue, but does this function lack validation for
transfer lengths?

If a DMA client driver provides a len of 0 in dma_chan_prep_dma_memcpy(),
num evaluates to 0 and the transfer setup loop is skipped. The function then
attempts to write to index -1, causing memory corruption:

	/* Set end-of-link to the last link descriptor of list */
	set_desc_last(&desc->hw_desc[num - 1]);

Similarly, in dw_axi_dma_chan_prep_cyclic(), can a period_len of 0 cause an
unhandled division-by-zero panic when calculating num_periods?

	num_periods = buf_len / period_len;

And if buf_len is 0 in dw_axi_dma_chan_prep_cyclic(), making total_segments 0,
does this access out of bounds on the 0-length allocation?

	llp = desc->hw_desc[0].llp;

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260828-dma-fix-v1-0-a6947f487e07@ultrarisc.com?part=1