Linux-ARM-Kernel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Guangshuo Li <lgs201920130244@gmail.com>
To: Patrice Chotard <patrice.chotard@foss.st.com>,
	Vinod Koul <vkoul@kernel.org>, Frank Li <Frank.Li@kernel.org>,
	Peter Griffin <peter.griffin@linaro.org>,
	Ludovic Barre <ludovic.barre@st.com>,
	linux-arm-kernel@lists.infradead.org, dmaengine@vger.kernel.org,
	linux-kernel@vger.kernel.org
Cc: Guangshuo Li <lgs201920130244@gmail.com>, stable@vger.kernel.org
Subject: [PATCH] dmaengine: st_fdma: fix potential use-after-free in vchan tasklets
Date: Sat, 12 Sep 2026 23:46:29 +0800	[thread overview]
Message-ID: <20260912154629.1021632-1-lgs201920130244@gmail.com> (raw)

st_fdma_probe() allocates the channel array with devm_kcalloc() and
initializes an embedded virt-dma tasklet for each st_fdma_chan through
vchan_init().

The interrupt handler calls vchan_cookie_complete() or
vchan_cyclic_callback(), which may schedule the tasklet. However,
st_fdma_remove() only frees the IRQ and does not kill already scheduled
tasklets.

devm_free_irq() prevents new interrupt handlers from running and waits
for an in-flight handler to finish, but it does not flush a tasklet
that was scheduled by a previous interrupt. Since fdev->chans is
devm-managed, the channel array is released after the remove callback
returns.

This leaves the following possible race:

  CPU0 (driver removal)                 CPU1 (IRQ / softirq)
  ---------------------                 --------------------
                                        st_fdma_irq_handler()
                                          vchan_cookie_complete()
                                            tasklet_schedule()
                                        return
                                        <tasklet pending>

  st_fdma_remove()
    devm_free_irq()
    ...
    return

  devres cleanup
    ...
    kfree(fdev->chans)                  // FREE
                                        vchan_complete()
                                          vc = from_tasklet(...)
                                          spin_lock_irq(&vc->lock)
                                                       // USE -> UAF

The pending tasklet is embedded in the devm-allocated st_fdma_chan.
Once fdev->chans is released, the tasklet and the virt_dma_chan
containing it point into freed memory. A later vchan_complete() can
therefore dereference the freed channel and cause a potential
use-after-free.

Kill all vchan tasklets after freeing the IRQ. This prevents new
interrupt handlers from scheduling them and waits for any tasklet that
is already pending or running before the channel storage can be
released.

This issue was found by manual code inspection.

Fixes: 6b4cd727eaf15 ("dmaengine: st_fdma: Add STMicroelectronics FDMA engine driver support")
Cc: stable@vger.kernel.org
Signed-off-by: Guangshuo Li <lgs201920130244@gmail.com>
---
 drivers/dma/st_fdma.c | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/drivers/dma/st_fdma.c b/drivers/dma/st_fdma.c
index d9547017f3bd..23071cbf1866 100644
--- a/drivers/dma/st_fdma.c
+++ b/drivers/dma/st_fdma.c
@@ -846,8 +846,13 @@ static int st_fdma_probe(struct platform_device *pdev)
 static void st_fdma_remove(struct platform_device *pdev)
 {
 	struct st_fdma_dev *fdev = platform_get_drvdata(pdev);
+	int i;
 
 	devm_free_irq(&pdev->dev, fdev->irq, fdev);
+
+	for (i = 0; i < fdev->nr_channels; i++)
+		tasklet_kill(&fdev->chans[i].vchan.task);
+
 	st_slim_rproc_put(fdev->slim_rproc);
 	of_dma_controller_free(pdev->dev.of_node);
 }
-- 
2.43.0



                 reply	other threads:[~2026-09-12 15:46 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=20260912154629.1021632-1-lgs201920130244@gmail.com \
    --to=lgs201920130244@gmail.com \
    --cc=Frank.Li@kernel.org \
    --cc=dmaengine@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=ludovic.barre@st.com \
    --cc=patrice.chotard@foss.st.com \
    --cc=peter.griffin@linaro.org \
    --cc=stable@vger.kernel.org \
    --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