Re: [PATCH v6 1/2] dmaengine: fsl-edma: Implement device_prep_peripheral_dma_vec

[Frank Li <Frank.li@oss.nxp.com>]

On Fri, Jul 10, 2026 at 12:23:58PM +0000, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 6 potential issue(s) to consider:
>
> New issues:
> - [High] Missing validation for maximum segment transfer length causes silent 16-bit truncation of the loop iteration count.
>
> Pre-existing issues:
> - [Critical] Unconditional division and modulo by zero occur during DMA_DEV_TO_DEV transfers due to hardcoded zero offsets.
> - [Critical] Missing `is_multi_fifo` and `port_window_size` handling causes the peripheral address pointer to permanently walk backwards.
> - [High] Missing validation for `nb == 0` leads to a zero-length flexible array allocation and a subsequent out-of-bounds access.
> - [High] Missing validation for slave configuration parameters allows clients to trigger a divide-by-zero crash.
> - [High] Calling `dma_map_resource` with `DMA_NONE` triggers a BUG_ON in the DMA mapping subsystem.
> --
>
...
>
> > +					nbytes = j * width;
> > +					break;
> > +				}
> > +			}
> > +			/* Set burst size as 1 if there's no suitable one */
> > +			if (j == 1)
> > +				nbytes = width;
> > +		}
> > +
> > +		iter = vecs[i].len / nbytes;
>
> [Severity: High]
> Does this properly handle vectors that exceed the hardware's maximum segment
> size?
>
> The dma_vec API passes raw vector lengths directly from the client, and
> iter is a u16. If vecs[i].len / nbytes exceeds 65535, will this silently
> truncate and lead to a partial transfer and data corruption?

Please check this problem

Frank
>
> [ ... ]
>
> --
> Sashiko AI review · https://sashiko.dev/#/patchset/20260710-fsl-edma-dyn-sg-v6-0-831b96be3f31@bootlin.com?part=1