* [PATCH v1] remoteproc: qcom_q6v5_mss: Leak metadata buffer if reclaim fails
@ 2026-11-05 17:32 Yuho Choi
2026-11-08 20:08 ` Bjorn Andersson
0 siblings, 1 reply; 2+ messages in thread
From: Yuho Choi @ 2026-11-05 17:32 UTC (permalink / raw)
To: Bjorn Andersson, Mathieu Poirier
Cc: linux-arm-msm, linux-remoteproc, linux-kernel, Yuho Choi
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
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: [PATCH v1] remoteproc: qcom_q6v5_mss: Leak metadata buffer if reclaim fails
2026-11-05 17:32 [PATCH v1] remoteproc: qcom_q6v5_mss: Leak metadata buffer if reclaim fails Yuho Choi
@ 2026-11-08 20:08 ` Bjorn Andersson
0 siblings, 0 replies; 2+ messages in thread
From: Bjorn Andersson @ 2026-11-08 20:08 UTC (permalink / raw)
To: Mathieu Poirier, Yuho Choi; +Cc: linux-arm-msm, linux-remoteproc, linux-kernel
On Thu, 05 Nov 2026 12:32:24 -0500, Yuho Choi wrote:
> 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.
>
> [...]
Applied, thanks!
[1/1] remoteproc: qcom_q6v5_mss: Leak metadata buffer if reclaim fails
commit: 3f4f7571c001b04622be50c288c73ec8f320beca
Best regards,
--
Bjorn Andersson <andersson@kernel.org>
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2026-11-08 20:08 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2026-11-05 17:32 [PATCH v1] remoteproc: qcom_q6v5_mss: Leak metadata buffer if reclaim fails Yuho Choi
2026-11-08 20:08 ` Bjorn Andersson
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®