All of lore.kernel.org
 help / color / mirror / Atom feed
From: Codex <samarth.colleges@gmail.com>
To: Ulf Hansson <ulfh@kernel.org>
Cc: linux-mmc@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-renesas-soc@vger.kernel.org,
	Samarth Narang <samarth.colleges@gmail.com>
Subject: [PATCH] mmc: sh_mmcif: unmap DMA buffers only after the transfer has stopped
Date: Fri, 30 Oct 2026 14:31:51 +0000	[thread overview]
Message-ID: <20261030143151.2916788-1-codex@local.invalid> (raw)

From: Samarth Narang <samarth.colleges@gmail.com>

When sh_mmcif_end_cmd() is woken by a data error interrupt or a DMA
timeout, the DMA descriptor may still be active. However, the function
unmaps data->sg before clearing BUF_ACC_DMAREN/DMAWEN and calling
dmaengine_terminate_sync(), potentially releasing the mapping while the
controller is still accessing it.

Since data errors can be triggered by the card, a faulty or malicious
card may cause DMA accesses to continue after unmapping, potentially
affecting reused IOVA or SWIOTLB mappings or causing premature cache
maintenance on non-coherent systems.

Move the unmap after DMA termination so that the mapping remains valid
until the transfer has either completed normally or been terminated
synchronously.

Fixes: eae309836509 ("mmc: sh_mmcif: Terminate DMA transactions when detecting timeout or error")
Assisted-by: LLM
Signed-off-by: Samarth Narang <samarth.colleges@gmail.com>
---
This issue was identified through static analysis of DMA lifecycle
ordering and has not been validated on hardware.

Since the request pages are not released until mmc_request_done() is
called after DMA termination, direct-mapped pages remain owned by the
request. The potential exposure is therefore limited to the DMA mapping
layer, including IOVA or SWIOTLB slot reuse and premature cache
maintenance on non-coherent systems.

The fix also relies on dmaengine_terminate_sync() stopping the channel
correctly on both MMCIF DMA providers. However, shdma clears CHCR.DE
without confirming that the channel has stopped, while rcar-dmac polls
the bit for approximately 1 ms but only logs a timeout if it remains
set.

 drivers/mmc/host/sh_mmcif.c |   23 ++++++++++++++---------
 1 file changed, 14 insertions(+), 9 deletions(-)

diff --git a/drivers/mmc/host/sh_mmcif.c b/drivers/mmc/host/sh_mmcif.c
index 8bd9cdeda..7b33f832b 100644
--- a/drivers/mmc/host/sh_mmcif.c
+++ b/drivers/mmc/host/sh_mmcif.c
@@ -1173,15 +1173,6 @@ static bool sh_mmcif_end_cmd(struct sh_mmcif_host *host)
 	time = wait_for_completion_interruptible_timeout(&host->dma_complete,
 							 host->timeout);
 
-	if (data->flags & MMC_DATA_READ)
-		dma_unmap_sg(host->chan_rx->device->dev,
-			     data->sg, data->sg_len,
-			     DMA_FROM_DEVICE);
-	else
-		dma_unmap_sg(host->chan_tx->device->dev,
-			     data->sg, data->sg_len,
-			     DMA_TO_DEVICE);
-
 	if (host->sd_error) {
 		dev_err(host->mmc->parent,
 			"Error IRQ while waiting for DMA completion!\n");
@@ -1208,6 +1199,20 @@ static bool sh_mmcif_end_cmd(struct sh_mmcif_host *host)
 			dmaengine_terminate_sync(host->chan_tx);
 	}
 
+	/*
+	 * An error IRQ or a timeout wakes us up while the DMA transfer may
+	 * still be running: only unmap once it has completed or been
+	 * terminated above.
+	 */
+	if (data->flags & MMC_DATA_READ)
+		dma_unmap_sg(host->chan_rx->device->dev,
+			     data->sg, data->sg_len,
+			     DMA_FROM_DEVICE);
+	else
+		dma_unmap_sg(host->chan_tx->device->dev,
+			     data->sg, data->sg_len,
+			     DMA_TO_DEVICE);
+
 	return false;
 }
 

base-commit: 24a19b953e2a3d0ea5a8c4951a0ab8f32720c907

             reply	other threads:[~2026-10-30 14:32 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-30 14:31 Codex [this message]
2026-10-30 14:36 ` [PATCH] mmc: sh_mmcif: unmap DMA buffers only after the transfer has stopped Samarth Narang

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=20261030143151.2916788-1-codex@local.invalid \
    --to=samarth.colleges@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mmc@vger.kernel.org \
    --cc=linux-renesas-soc@vger.kernel.org \
    --cc=ulfh@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.