DMA Engine development
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Devendra K Verma" <devendra.verma@amd.com>
Cc: vkoul@kernel.org, Frank.Li@kernel.org, dmaengine@vger.kernel.org
Subject: Re: [PATCH v1] dmaengine: dw-edma: Add Xilinx CPM6 DMA Device ID
Date: Thu, 28 May 2026 10:43:28 +0000	[thread overview]
Message-ID: <20260528104328.92F7E1F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260528101202.1244624-1-devendra.verma@amd.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Critical] Configuring 64 read and write channels for the new Xilinx CPM6 DMA device causes severe heap out-of-bounds reads during probe.
--

commit f926ec7cda085a4bb6bcd59ed57d0e183c1d998f
Author: Devendra K Verma <devverma@amd.com>

dmaengine: dw-edma: Add Xilinx CPM6 DMA Device ID

This commit adds the device ID and configuration for the Xilinx CPM6 DMA IP.
It sets up the device data to support 64 read and 64 write channels.

> diff --git a/drivers/dma/dw-edma/dw-edma-pcie.c b/drivers/dma/dw-edma/dw-edma-pcie.c
> index 0b30ce1385036..c5e0411428693 100644
> --- a/drivers/dma/dw-edma/dw-edma-pcie.c
> +++ b/drivers/dma/dw-edma/dw-edma-pcie.c
[ ... ]
> @@ -125,6 +126,19 @@ static const struct dw_edma_pcie_data xilinx_mdb_data = {
>  	.rd_ch_cnt			= 8,
>  };
>  
> +static const struct dw_edma_pcie_data xilinx_cpm6_dma_data = {
> +	/* MDB registers location */
> +	.rg.bar				= BAR_0,
> +	.rg.off				= SZ_4K,	/*  4 Kbytes */
> +	.rg.sz				= SZ_8K,	/*  8 Kbytes */
> +
> +	/* Other */
> +	.mf				= EDMA_MF_HDMA_NATIVE,
> +	.irqs				= 1,
> +	.wr_ch_cnt			= 64,
> +	.rd_ch_cnt			= 64,

[Severity: Critical]
Will setting these channel counts to 64 cause out-of-bounds reads during probe?

Looking at struct dw_edma_pcie_data, the ll_wr array is statically sized
to EDMA_MAX_WR_CH (which is 8).

While out-of-bounds writes are prevented because Xilinx devices implicitly set
non_ll = true, several loops in dw_edma_pcie_probe() unconditionally iterate
up to wr_ch_cnt and rd_ch_cnt without checking non_ll.

For example, the loop computing the PCI BAR region mask executes
mask |= BIT(vsec_data->ll_wr[i].bar) for i up to 63. This will read
significantly past the end of the vsec_data structure.

Can this corrupt the BAR mask with garbage data and lead to an immediate
kernel panic if the allocation is near a page boundary or has KASAN redzones?

> +};
> +

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260528101202.1244624-1-devendra.verma@amd.com?part=1

  reply	other threads:[~2026-05-28 10:43 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-28 10:12 [PATCH v1] dmaengine: dw-edma: Add Xilinx CPM6 DMA Device ID Devendra K Verma
2026-05-28 10:43 ` sashiko-bot [this message]
2026-05-28 11:23 ` 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=20260528104328.92F7E1F000E9@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=Frank.Li@kernel.org \
    --cc=devendra.verma@amd.com \
    --cc=dmaengine@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox