Re: [PATCH v2 2/4] dmaengine: dw-axi-dmac: Fix LLI dump out-of-bounds access

[sashiko-bot@kernel.org]

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

Pre-existing issues:
- [Critical] The patch fixes an out-of-bounds access in `axi_chan_list_dump_lli()` by using the transaction-local `desc->nr_hw_descs` instead of the channel-wide `chan->descs_allocated`. However, it completely misses the exact same bug in `axi_chan_block_xfer_complete()` which can lead to memory corruption.
- [Critical] Flawed calculations for `segment_len` and loop bounds in both `dw_axi_dma_chan_prep_slave_sg` and `dw_axi_dma_chan_prep_cyclic` lead to data truncation, DMA overruns, and NULL pointer dereferences when buffer lengths are not perfectly divisible by the calculated `segment_len`.
--

commit 5ff010f18efeeec7fde7f85a181da39448ad009d
Author: Jia Wang <wangjia@ultrarisc.com>

dmaengine: dw-axi-dmac: Fix LLI dump out-of-bounds access

This commit fixes an out-of-bounds access in axi_chan_list_dump_lli() by
using the transaction-local descriptor count instead of the channel-wide
count.

> 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 742e08cfab435..61230d2b1c561 100644
> --- a/drivers/dma/dw-axi-dmac/dw-axi-dmac-platform.c
> +++ b/drivers/dma/dw-axi-dmac/dw-axi-dmac-platform.c
> @@ -1052,10 +1052,7 @@ static void axi_chan_dump_lli(struct axi_dma_chan *chan,
>  static void axi_chan_list_dump_lli(struct axi_dma_chan *chan,
>  				   struct axi_dma_desc *desc_head)
>  {
> -	int count = atomic_read(&chan->descs_allocated);
> -	int i;
> -
> -	for (i = 0; i < count; i++)
> +	for (unsigned int i = 0; i < desc_head->nr_hw_descs; i++)
>  		axi_chan_dump_lli(chan, &desc_head->hw_desc[i]);
>  }

[Severity: Critical]
This is a pre-existing issue, but does axi_chan_block_xfer_complete() have
the same out-of-bounds access regression?

If multiple transactions are prepared, chan->descs_allocated can exceed the
transaction-local desc->nr_hw_descs:

drivers/dma/dw-axi-dmac/dw-axi-dmac-platform.c:axi_chan_block_xfer_complete() {
    ...
    int count = atomic_read(&chan->descs_allocated);
    ...
    if (chan->cyclic) {
        desc = vd_to_axi_desc(vd);
        if (desc) {
            llp = lo_hi_readq(chan->chan_regs + CH_LLP);
            for (i = 0; i < count; i++) {
                hw_desc = &desc->hw_desc[i];
                if (hw_desc->llp == llp) {
                    axi_chan_irq_clear(chan, hw_desc->lli->status_lo);
                    hw_desc->lli->ctl_hi |= cpu_to_le32(CH_CTL_H_LLI_VALID);
    ...
}

Could this cause an out-of-bounds read on the desc->hw_desc array, and
corrupt memory when writing to hw_desc->lli->ctl_hi?

[Severity: Critical]
This is also a pre-existing issue, but can the segment loop bounds cause
data truncation or memory overruns?

In dw_axi_dma_chan_prep_slave_sg(), if len is not perfectly divisible by
segment_len, the loop terminates prematurely:

drivers/dma/dw-axi-dmac/dw-axi-dmac-platform.c:dw_axi_dma_chan_prep_slave_sg() {
    ...
    do {
        hw_desc = &desc->hw_desc[loop++];
        status = dw_axi_dma_set_hw_desc(chan, hw_desc, mem, segment_len);
        ...
        len -= segment_len;
        mem += segment_len;
    } while (len >= segment_len);
    ...
}

Does this drop the remainder bytes and leave trailing descriptors
uninitialized, causing a NULL dereference when set_desc_last() is called?

Similarly, in dw_axi_dma_chan_prep_cyclic():

drivers/dma/dw-axi-dmac/dw-axi-dmac-platform.c:dw_axi_dma_chan_prep_cyclic() {
    ...
    for (i = 0; i < total_segments; i++) {
        hw_desc = &desc->hw_desc[i];
        status = dw_axi_dma_set_hw_desc(chan, hw_desc, src_addr, segment_len);
        ...
        src_addr += segment_len;
    }
    ...
}

Can this unconditionally program the DMA to transfer segment_len for each
segment, exceeding the requested period_len and reading or writing past the
end of the provided DMA buffer?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260901-dma-fix-v2-0-d7f0459ebb14@ultrarisc.com?part=2