From: sashiko-bot@kernel.org
To: Frank.Li@oss.nxp.com
Cc: linux-pci@vger.kernel.org, Frank.Li@kernel.org,
dmaengine@vger.kernel.org, imx@lists.linux.dev, vkoul@kernel.org
Subject: Re: [PATCH v6 09/10] dmaengine: dw-edma: Use burst array instead of linked list
Date: Fri, 10 Jul 2026 17:07:08 +0000 [thread overview]
Message-ID: <20260710170708.ACD611F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260710-edma_ll-v6-9-1471d278b73a@nxp.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Critical] In non-linked-list (non_ll) mode, the burst array index is incorrectly calculated using `chan->ll_max` instead of `bursts_max`. This causes a heap buffer overflow and leaves the actual DMA descriptor uninitialized.
--
--- Patch [9]: [PATCH v6 09/10] dmaengine: dw-edma: Use burst array instead of linked list ---
commit 755f4cc5fb98a43f3634cf5e1dc7f15a35af8c49
Author: Frank Li <Frank.Li@nxp.com>
dmaengine: dw-edma: Use burst array instead of linked list
Creating a DMA descriptor requires at least three kzalloc() calls because
each burst is allocated as a linked-list node. This commit allocates a
burst array when creating each chunk to simplify the code and eliminate
one kzalloc() call.
> diff --git a/drivers/dma/dw-edma/dw-edma-core.c b/drivers/dma/dw-edma/dw-edma-core.c
> index f52d9fd18e573..202862a828b4d 100644
> --- a/drivers/dma/dw-edma/dw-edma-core.c
> +++ b/drivers/dma/dw-edma/dw-edma-core.c
[ ... ]
> @@ -166,23 +103,17 @@ static void vchan_free_desc(struct virt_dma_desc *vdesc)
> static void dw_edma_core_start(struct dw_edma_chunk *chunk, bool first)
> {
> struct dw_edma_chan *chan = chunk->chan;
> - struct dw_edma_burst *child;
> u32 i = 0;
> - int j;
>
> if (chan->non_ll) {
> - child = list_first_entry_or_null(&chunk->burst->list,
> - struct dw_edma_burst, list);
> - if (child)
> - chan->dw->core->non_ll_start(chunk->chan, child);
> + if (chunk->nburst == 1)
> + chan->dw->core->non_ll_start(chunk->chan, &chunk->burst[0]);
[Severity: Critical]
If chunk->burst[0] is bypassed during allocation in dw_edma_device_transfer()
when i > 0, does this code submit an uninitialized descriptor to the
hardware?
[ ... ]
> @@ -530,15 +456,15 @@ dw_edma_device_transfer(struct dw_edma_transfer *xfer,
> if (xfer->type == EDMA_XFER_SCATTER_GATHER && !sg)
> break;
>
> - if (chunk->bursts_alloc == bursts_max) {
> - chunk = dw_edma_alloc_chunk(desc);
> + if (!(i % bursts_max)) {
> + u32 n = min(cnt - i, bursts_max);
> +
> + chunk = dw_edma_alloc_chunk(desc, n);
> if (unlikely(!chunk))
> goto err_alloc;
> }
>
> - burst = dw_edma_alloc_burst(chunk);
> - if (unlikely(!burst))
> - goto err_alloc;
> + burst = chunk->burst + (i % chan->ll_max);
[Severity: Critical]
Does this code overflow chunk->burst[] when chan->non_ll is true?
If chan->non_ll is true, bursts_max is 1, so dw_edma_alloc_chunk() allocates
a chunk with a 1-element burst array for each i. However, burst is indexed
using chan->ll_max.
For example, when i = 1:
- i % bursts_max is 0, so a new chunk is allocated with nburst = 1.
- If chan->ll_max > 1, i % chan->ll_max is 1.
- burst is set to &chunk->burst[1], which is out of bounds.
Consequently, chunk->burst[0] remains uninitialized.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260710-edma_ll-v6-0-1471d278b73a@nxp.com?part=9
next prev parent reply other threads:[~2026-07-10 17:07 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-10 16:47 [PATCH v6 00/10] dmaengine: dw-edma: flatten desc structions and simplify code Frank.Li
2026-07-10 16:47 ` [PATCH v6 01/10] dmaengine: dw-edma: Move control field update of DMA link to the last step Frank.Li
2026-07-10 16:57 ` sashiko-bot
2026-07-10 16:47 ` [PATCH v6 02/10] dmaengine: dw-edma: Add xfer_sz field to struct dw_edma_chunk Frank.Li
2026-07-10 16:56 ` sashiko-bot
2026-07-10 16:47 ` [PATCH v6 03/10] dmaengine: dw-edma: Move ll_region from struct dw_edma_chunk to struct dw_edma_chan Frank.Li
2026-07-10 17:05 ` sashiko-bot
2026-07-10 16:47 ` [PATCH v6 04/10] dmaengine: dw-edma: Pass down dw_edma_chan to reduce one level of indirection Frank.Li
2026-07-10 16:56 ` sashiko-bot
2026-07-10 16:47 ` [PATCH v6 05/10] dmaengine: dw-edma: Add helper dw_(edma|hdma)_v0_core_ch_enable() Frank.Li
2026-07-10 16:56 ` sashiko-bot
2026-07-10 16:47 ` [PATCH v6 06/10] dmaengine: dw-edma: Add callbacks to fill link list entries Frank.Li
2026-07-10 16:59 ` sashiko-bot
2026-07-10 16:47 ` [PATCH v6 07/10] dmaengine: dw-edma: Add non_ll_start() callback Frank.Li
2026-07-10 17:04 ` sashiko-bot
2026-07-10 16:47 ` [PATCH v6 08/10] dmaengine: dw-edma: Use common dw_edma_core_start() for both eDMA and HDMA Frank.Li
2026-07-10 17:03 ` sashiko-bot
2026-07-10 16:47 ` [PATCH v6 09/10] dmaengine: dw-edma: Use burst array instead of linked list Frank.Li
2026-07-10 17:07 ` sashiko-bot [this message]
2026-07-10 16:47 ` [PATCH v6 10/10] dmaengine: dw-edma: Remove struct dw_edma_chunk Frank.Li
2026-07-10 17:08 ` sashiko-bot
2026-07-10 17:23 ` [PATCH v6 00/10] dmaengine: dw-edma: flatten desc structions and simplify code Verma, Devendra
2026-07-10 17:28 ` Verma, Devendra
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260710170708.ACD611F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=Frank.Li@kernel.org \
--cc=Frank.Li@oss.nxp.com \
--cc=dmaengine@vger.kernel.org \
--cc=imx@lists.linux.dev \
--cc=linux-pci@vger.kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
--cc=vkoul@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.