mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Yuho Choi <oss.patchbox@gmail.com>
To: Bjorn Andersson <andersson@kernel.org>,
	Mathieu Poirier <mathieu.poirier@linaro.org>
Cc: linux-arm-msm@vger.kernel.org, linux-remoteproc@vger.kernel.org,
	linux-kernel@vger.kernel.org, Yuho Choi <oss.patchbox@gmail.com>
Subject: [PATCH v1] remoteproc: qcom_q6v5_mss: Leak metadata buffer if reclaim fails
Date: Thu,  5 Nov 2026 12:32:24 -0500	[thread overview]
Message-ID: <20261105173336.32359-2-oss.patchbox@gmail.com> (raw)

When the device tree describes no "metadata" memory region,
q6v5_mpss_init_image() allocates the MPSS metadata buffer with
dma_alloc_attrs(), assigns it to the modem and asks the MBA to
authenticate it. It then calls q6v5_xfer_mem_ownership() again to
assign the buffer back to HLOS.

If that second call fails, the buffer is still assigned to the modem,
but the function only warns and then returns the buffer to the DMA
allocator. The pages can then be reused by another part of the kernel
while the modem can still access them.

Leak the buffer in that case instead. The driver has no later point at
which it could retry the reassignment. The MBA and MPSS regions and a
"metadata" region from the device tree are never freed, so this is the
only place where a buffer that failed to be reclaimed goes back to the
allocator.

Fixes: 6c5a9dc2481b ("remoteproc: qcom: Make secure world call for mem ownership switch")
Signed-off-by: Yuho Choi <oss.patchbox@gmail.com>
---
This was found with a static analysis tool from ongoing, not yet
published research, and confirmed by code inspection. Compile-tested
only (arm64 defconfig, W=1); I have no Qualcomm board with a modem to
test it on.

 drivers/remoteproc/qcom_q6v5_mss.c | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/remoteproc/qcom_q6v5_mss.c b/drivers/remoteproc/qcom_q6v5_mss.c
index 2f71ed2feff6..1a5afce4e6c1 100644
--- a/drivers/remoteproc/qcom_q6v5_mss.c
+++ b/drivers/remoteproc/qcom_q6v5_mss.c
@@ -1128,9 +1128,12 @@ static int q6v5_mpss_init_image(struct q6v5 *qproc, const struct firmware *fw,
 	/* Metadata authentication done, remove modem access */
 	xferop_ret = q6v5_xfer_mem_ownership(qproc, &mdata_perm, true, false,
 					     phys, size);
-	if (xferop_ret)
+	if (xferop_ret) {
 		dev_warn(qproc->dev,
 			 "mdt buffer not reclaimed system may become unstable\n");
+		/* The modem may still have access to the buffer, so leak it */
+		goto free_metadata;
+	}
 
 free_dma_attrs:
 	if (!qproc->mdata_phys)

base-commit: 8396089f91fa07dd77b580e045334e670f782ff8
-- 
2.43.0


                 reply	other threads:[~2026-11-05 17:33 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=20261105173336.32359-2-oss.patchbox@gmail.com \
    --to=oss.patchbox@gmail.com \
    --cc=andersson@kernel.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-remoteproc@vger.kernel.org \
    --cc=mathieu.poirier@linaro.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

all inboxes | Powered by JetHome®