All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: Frank.Li@oss.nxp.com
Cc: dmaengine@vger.kernel.org, linux-pci@vger.kernel.org,
	Frank.Li@kernel.org, vkoul@kernel.org, imx@lists.linux.dev
Subject: Re: [PATCH v6 2/9] dmaengine: Add safe API to combine configuration and preparation
Date: Thu, 21 May 2026 00:01:04 +0000	[thread overview]
Message-ID: <20260521000104.CC1891F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260520-dma_prep_config-v6-2-06e49b7acb38@nxp.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Critical] Stack-allocated scatterlist in dmaengine_prep_config_single_safe() leads to use-after-free when consumed asynchronously by DMA drivers.
--

commit 7f280444e5ae16961e6f77cb674cd3ac061779a0
Author: Frank Li <Frank.Li@nxp.com>

dmaengine: Add safe API to combine configuration and preparation

This commit introduces two helpers to combine DMA slave configuration and
transfer preparation atomically. Drivers can either provide a new callback
or the helpers will serialize the operations using a per-channel spinlock.

> diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
> index defa377d2ef54..6fe46c0c94527 100644
> --- a/include/linux/dmaengine.h
> +++ b/include/linux/dmaengine.h
[ ... ]
> +static inline struct dma_async_tx_descriptor *
> +dmaengine_prep_config_single_safe(struct dma_chan *chan, dma_addr_t buf,
> +				  size_t len, enum dma_transfer_direction dir,
> +				  unsigned long flags,
> +				  struct dma_slave_config *config)
> +{
> +	struct scatterlist sg;
> +
> +	sg_init_table(&sg, 1);
> +	sg_dma_address(&sg) = buf;
> +	sg_dma_len(&sg) = len;
> +
> +	return dmaengine_prep_config_sg_safe(chan, &sg, 1, dir, flags, config);

[Severity: Critical]
Can this lead to a use-after-free if the DMA driver consumes the scatterlist
asynchronously?

The scatterlist sg is allocated on the stack here. While some drivers might
process the scatterlist synchronously during the device_prep_slave_sg or
device_prep_config_sg callbacks, others (such as qdma) may save the sgl
pointer internally to process later during tx_submit or hardware enqueue.

By the time the driver accesses the saved sgl pointer, this function will
have returned and the stack frame will be destroyed.

> +}
> +
>  #ifdef CONFIG_RAPIDIO_DMA_ENGINE

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260520-dma_prep_config-v6-0-06e49b7acb38@nxp.com?part=2

  reply	other threads:[~2026-05-21  0:01 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-20 22:00 [PATCH v6 0/9] dmaengine: Add new API to combine configuration and descriptor preparation Frank.Li
2026-05-20 22:00 ` [PATCH v6 1/9] dmaengine: Add API to combine configuration and preparation (sg and single) Frank.Li
2026-05-20 22:00 ` [PATCH v6 2/9] dmaengine: Add safe API to combine configuration and preparation Frank.Li
2026-05-21  0:01   ` sashiko-bot [this message]
2026-05-21 14:56     ` Frank Li
2026-05-20 22:00 ` [PATCH v6 3/9] PCI: endpoint: pci-epf-test: Use dmaenigne_prep_config_single() to simplify code Frank.Li
2026-05-20 22:00 ` [PATCH v6 4/9] dmaengine: dw-edma: Use new .device_prep_config_sg() callback Frank.Li
2026-05-21  0:31   ` sashiko-bot
2026-05-21 14:59     ` Frank Li
2026-05-20 22:00 ` [PATCH v6 5/9] dmaengine: dw-edma: Pass dma_slave_config to dw_edma_device_transfer() Frank.Li
2026-05-21  0:51   ` sashiko-bot
2026-05-21 15:02     ` Frank Li
2026-05-20 22:00 ` [PATCH v6 6/9] nvmet: pci-epf: Remove unnecessary dmaengine_terminate_sync() on each DMA transfer Frank.Li
2026-05-20 22:00 ` [PATCH v6 7/9] nvmet: pci-epf: Use dmaengine_prep_config_single_safe() API Frank.Li
2026-05-21  1:39   ` sashiko-bot
2026-05-21 15:08     ` Frank Li
2026-05-20 22:00 ` [PATCH v6 8/9] PCI: epf-mhi: Use dmaengine_prep_config_single() to simplify code Frank.Li
2026-05-21  2:08   ` sashiko-bot
2026-05-21 15:09     ` Frank Li
2026-05-20 22:00 ` [PATCH v6 9/9] crypto: atmel: Use dmaengine_prep_config_sg() API Frank.Li
2026-05-21  2:33   ` sashiko-bot
2026-05-21 15:11     ` Frank Li

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=20260521000104.CC1891F000E9@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.