[PATCH v1 0/4] arm64: dts: qcom: Make ADSP remote heaps no-map

[PATCH v1 0/4] arm64: dts: qcom: Make ADSP remote heaps no-map

[Jianping Li]

Several Qualcomm platforms declare the ADSP remote heap as a reusable
shared DMA pool. This allows the kernel to reuse the region for movable
allocations.

When FastRPC assigns the entire region to the DSP without first
allocating its pages from CMA, those pages remain available for HLOS
allocations despite HLOS access permissions having been revoked.
Subsequent kernel accesses can therefore cause synchronous external
aborts.

This issue has been reported on Talos during GPU stress testing and on
Kodiak during storage testing. A further report on a Kodiak-based
Motorola Edge 30 describes similar aborts during everyday use and
indicates that marking the heap no-map resolves the issue.

Following feedback on the Talos patch, this series updates the remaining
identified reusable ADSP remote heaps on Kodiak, Glymur, SM8250 and
SM8750. Each platform is handled in a separate patch to allow independent
review and backporting.

Replace reusable with no-map to prevent normal kernel allocations from
using these regions and exclude them from the kernel's standard memory
mapping. The existing allocation ranges, alignment and sizes are
unchanged.

The Talos fix was submitted separately [1]. Agatti is also excluded
because a separate fix has already been posted [2].

[1] https://lore.kernel.org/all/20261014083820.468-1-jianping.li@oss.qualcomm.com/
[2] https://lore.kernel.org/all/20261001085247.1897991-1-benjamin@wendy.sh/

Jianping Li (4):
  arm64: dts: qcom: kodiak: Make the ADSP remote heap no-map
  arm64: dts: qcom: glymur: Make the ADSP remote heap no-map
  arm64: dts: qcom: sm8250: Make the ADSP remote heap no-map
  arm64: dts: qcom: sm8750: Make the ADSP remote heap no-map

 arch/arm64/boot/dts/qcom/glymur.dtsi | 2 +-
 arch/arm64/boot/dts/qcom/kodiak.dtsi | 2 +-
 arch/arm64/boot/dts/qcom/sm8250.dtsi | 2 +-
 arch/arm64/boot/dts/qcom/sm8750.dtsi | 2 +-
 4 files changed, 4 insertions(+), 4 deletions(-)

-- 
2.43.0

[PATCH v1 1/4] arm64: dts: qcom: kodiak: Make the ADSP remote heap no-map

[Jianping Li]

The ADSP remote heap is declared as a reusable CMA pool. FastRPC
assigns the entire region to the DSP through qcom_scm_assign_mem()
during probe without allocating the pages from CMA. Consequently,
the pages remain available for movable HLOS allocations even after
HLOS access to the region has been revoked.

On Kodiak, a synchronous external abort was reported during storage
testing when the kernel accessed memory within the ADSP remote heap.
The faulting address was outside the HLOS stage-2 mapping.

Replace reusable with no-map to prevent the region from being reused
for normal kernel allocations and exclude it from the kernel's
standard memory mapping.

Fixes: 9d7d847ff1c50 ("arm64: dts: qcom: kodiak: avoid EFI overlap for ADSP remote heap")
Link: https://lore.kernel.org/all/20260423063502.484-1-jianping.li@oss.qualcomm.com/
Signed-off-by: Jianping Li <jianping.li@oss.qualcomm.com>
---
 arch/arm64/boot/dts/qcom/kodiak.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/qcom/kodiak.dtsi b/arch/arm64/boot/dts/qcom/kodiak.dtsi
index 8c7523602d27..057d7e62b2dd 100644
--- a/arch/arm64/boot/dts/qcom/kodiak.dtsi
+++ b/arch/arm64/boot/dts/qcom/kodiak.dtsi
@@ -194,7 +194,7 @@ rmtfs_mem: rmtfs@9c900000 {
 		adsp_rpc_remote_heap_mem: adsp-rpc-remote-heap {
 			compatible = "shared-dma-pool";
 			alloc-ranges = <0x0 0x80000000 0x0 0x80000000>;
-			reusable;
+			no-map;
 			alignment = <0x0 0x400000>;
 			size = <0x0 0x800000>;
 		};
-- 
2.43.0

[PATCH v1 2/4] arm64: dts: qcom: glymur: Make the ADSP remote heap no-map

[Jianping Li]

The ADSP remote heap is declared as a reusable shared DMA pool.
Allowing the kernel to reuse this region is incompatible with handing
the entire region over to the DSP, as HLOS allocations may then access
memory for which HLOS no longer has access permissions.

The same configuration has caused synchronous external aborts on
other platforms when the kernel accesses pages within the ADSP remote
heap.

Replace reusable with no-map to keep the region reserved for the DSP
and exclude it from the kernel's standard memory mapping.

Fixes: 67641246eabd0 ("arm64: dts: qcom: glymur: Add memory-region for audio PD")
Link: https://lore.kernel.org/all/20260701-glymur-audio-v1-1-2c3862d95a09@oss.qualcomm.com/
Signed-off-by: Jianping Li <jianping.li@oss.qualcomm.com>
---
 arch/arm64/boot/dts/qcom/glymur.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/qcom/glymur.dtsi b/arch/arm64/boot/dts/qcom/glymur.dtsi
index 65a398c0a992..4b7907cf9c82 100644
--- a/arch/arm64/boot/dts/qcom/glymur.dtsi
+++ b/arch/arm64/boot/dts/qcom/glymur.dtsi
@@ -690,7 +690,7 @@ smem_mem: smem@ffe00000 {
 		adsp_rpc_remote_heap_mem: adsp-rpc-remote-heap {
 			compatible = "shared-dma-pool";
 			alloc-ranges = <0x0 0x80000000 0x0 0x80000000>;
-			reusable;
+			no-map;
 			alignment = <0x0 0x400000>;
 			size = <0x0 0x800000>;
 		};
-- 
2.43.0

[PATCH v1 3/4] arm64: dts: qcom: sm8250: Make the ADSP remote heap no-map

[Jianping Li]

The ADSP remote heap is declared as a reusable CMA pool. FastRPC
assigns the entire region to the DSP during probe without allocating
the pages from CMA. This allows movable HLOS allocations to use pages
within the region after HLOS access permissions have been revoked,
potentially causing synchronous external aborts.

Replace reusable with no-map to prevent the region from being reused
for normal kernel allocations and exclude it from the kernel's
standard memory mapping.

Fixes: 531ce288b6dd4 ("arm64: dts: qcom: sm8250: Add memory-region for audio PD")
Link: https://lore.kernel.org/all/20260619-sm8250-audio-v1-1-8a76e033e209@oss.qualcomm.com/
Signed-off-by: Jianping Li <jianping.li@oss.qualcomm.com>
---
 arch/arm64/boot/dts/qcom/sm8250.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/qcom/sm8250.dtsi b/arch/arm64/boot/dts/qcom/sm8250.dtsi
index f975c2183269..f415da478c99 100644
--- a/arch/arm64/boot/dts/qcom/sm8250.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8250.dtsi
@@ -867,7 +867,7 @@ cdsp_secure_heap: memory@8bf00000 {
 		adsp_rpc_remote_heap_mem: adsp-rpc-remote-heap {
 			compatible = "shared-dma-pool";
 			alloc-ranges = <0x0 0x80000000 0x0 0x80000000>;
-			reusable;
+			no-map;
 			alignment = <0x0 0x400000>;
 			size = <0x0 0x800000>;
 		};
-- 
2.43.0

[PATCH v1 4/4] arm64: dts: qcom: sm8750: Make the ADSP remote heap no-map

[Jianping Li]

The ADSP remote heap is declared as a reusable shared DMA pool.
Allowing the kernel to reuse this region is incompatible with handing
the entire region over to the DSP, as HLOS allocations may access
pages for which HLOS no longer has access permissions.

The same configuration has caused synchronous external aborts on
other platforms when the kernel accesses pages within the ADSP remote
heap.

Replace reusable with no-map to keep the region reserved for the DSP
and exclude it from the kernel's standard memory mapping.

Fixes: 0bcf9ca23a873 ("arm64: dts: qcom: sm8750: add memory node for adsp fastrpc")
Link: https://lore.kernel.org/all/20251209-sm8750-fastrpc-adsp-v3-1-ccfff49a8af9@linaro.org/
Signed-off-by: Jianping Li <jianping.li@oss.qualcomm.com>
---
 arch/arm64/boot/dts/qcom/sm8750.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/qcom/sm8750.dtsi b/arch/arm64/boot/dts/qcom/sm8750.dtsi
index cf947acc5760..0d493359408b 100644
--- a/arch/arm64/boot/dts/qcom/sm8750.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8750.dtsi
@@ -561,7 +561,7 @@ adsp_rpc_remote_heap_mem: adsp-rpc-remote-heap {
 			alloc-ranges = <0x0 0x00000000 0x0 0xffffffff>;
 			alignment = <0x0 0x400000>;
 			size = <0x0 0xc00000>;
-			reusable;
+			no-map;
 		};
 	};
 
-- 
2.43.0

Re: [PATCH v1 2/4] arm64: dts: qcom: glymur: Make the ADSP remote heap no-map

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] arm64/dma: Incomplete protection against speculative aborts for shared-dma-pool with no-map
--

commit 406984dd5e0c9e02f86eace82d9c1edf7af73157
Author: Jianping Li <jianping.li@oss.qualcomm.com>

arm64: dts: qcom: glymur: Make the ADSP remote heap no-map

This patch replaces the reusable property with no-map for the ADSP remote
heap to exclude it from the standard kernel memory mapping. This is intended
to prevent synchronous external aborts caused by kernel accesses after the
memory is handed over to the DSP.

Link: https://lore.kernel.org/all/20260701-glymur-audio-v1-1-2c3862d95a09@oss.qualcomm.com/

> diff --git a/arch/arm64/boot/dts/qcom/glymur.dtsi b/arch/arm64/boot/dts/qcom/glymur.dtsi
> index f04058d2e0891..ddbacc21f780e 100644
> --- a/arch/arm64/boot/dts/qcom/glymur.dtsi
> +++ b/arch/arm64/boot/dts/qcom/glymur.dtsi
> @@ -691,7 +691,7 @@ smem_mem: smem@ffe00000 {
>  		adsp_rpc_remote_heap_mem: adsp-rpc-remote-heap {
>  			compatible = "shared-dma-pool";
>  			alloc-ranges = <0x0 0x80000000 0x0 0x80000000>;
> -			reusable;
> +			no-map;

[Severity: High]
Does this fully protect against speculative aborts when combined with
the compatible = "shared-dma-pool" property?

Because the reusable property is removed but shared-dma-pool remains, the
reserved memory framework handles this node via rmem_dma_setup() in
kernel/dma/coherent.c. 

When the FastRPC driver probes and binds to this region via
of_reserved_mem_device_init(), it maps the entire 8MB physical region into
the kernel's vmalloc space:

kernel/dma/coherent.c:dma_init_coherent_memory() {
    ...
    mem_base = memremap(phys_addr, size, MEMREMAP_WC);
    ...
}

On the ARM architecture, MEMREMAP_WC creates a Normal Non-Cacheable mapping.
The architecture permits the CPU to perform speculative data reads on any
Normal memory, including Normal Non-Cacheable.

When the FastRPC driver allocates memory from this pool and assigns it to the
DSP via qcom_scm_assign_mem() (which revokes host access), this persistent
Normal memory mapping in vmalloc space remains intact.

Could speculative CPU reads through this vmalloc mapping still trigger the
exact same synchronous external aborts this patch aims to prevent?

>  			alignment = <0x0 0x400000>;
>  			size = <0x0 0x800000>;
>  		};

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261015071511.977-1-jianping.li@oss.qualcomm.com?part=2

Re: [PATCH v1 4/4] arm64: dts: qcom: sm8750: Make the ADSP remote heap no-map

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] fastrpc: missing HLOS permission restore causes dma_alloc_coherent crash
--

commit 7b6c7a04a288b135d8a9c50d62b4084748ab88f0
Author: Jianping Li <jianping.li@oss.qualcomm.com>

arm64: dts: qcom: sm8750: Make the ADSP remote heap no-map

This commit changes the ADSP remote heap declaration from a reusable shared
DMA pool to a no-map region. This is intended to prevent the kernel from
accessing pages that have been handed over to the DSP.

Link: https://lore.kernel.org/all/20251209-sm8750-fastrpc-adsp-v3-1-ccfff49a8af9@linaro.org/

> diff --git a/arch/arm64/boot/dts/qcom/sm8750.dtsi b/arch/arm64/boot/dts/qcom/sm8750.dtsi
> index dd738d13df8e0..ad71d30377c70 100644
> --- a/arch/arm64/boot/dts/qcom/sm8750.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sm8750.dtsi
> @@ -560,7 +560,7 @@ adsp_rpc_remote_heap_mem: adsp-rpc-remote-heap {
>  			alloc-ranges = <0x0 0x00000000 0x0 0xffffffff>;
>  			alignment = <0x0 0x400000>;
>  			size = <0x0 0xc00000>;
> -			reusable;
> +			no-map;

[Severity: High]
Does changing this region to no-map expose a missing permission restore issue
in the fastrpc driver that could lead to a synchronous external abort?

In fastrpc_req_mmap(), the memory is assigned to the DSP, which removes HLOS
permissions:

drivers/misc/fastrpc.c:fastrpc_req_mmap() {
    ...
    err = qcom_scm_assign_mem(buf->dma_addr, (u64)buf->size,
        &src_perms, fl->cctx->vmperms, fl->cctx->vmcount);
    ...
}

When the memory is freed via fastrpc_req_munmap_impl(), it calls
fastrpc_buf_free() without restoring the HLOS permissions first:

drivers/misc/fastrpc.c:fastrpc_buf_free() {
    ...
    dma_free_coherent(buf->dev, buf->size, buf->virt,
              fastrpc_ipa_to_dma_addr(buf->fl->cctx, buf->dma_addr));
    ...
}

Because this patch changes the memory to no-map, the allocation is moved
to the DMA coherent pool. When the freed block is returned to the pool,
the next allocation from that pool will execute a memset():

kernel/dma/coherent.c:__dma_alloc_from_coherent() {
    ...
    memset(ret, 0, size);
    ...
}

Could this memset() trigger a kernel panic due to the missing HLOS
permissions on the re-issued memory block?

>  		};
>  	};

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261015071511.977-1-jianping.li@oss.qualcomm.com?part=4

Re: [PATCH v1 1/4] arm64: dts: qcom: kodiak: Make the ADSP remote heap no-map

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] arm64: dts: qcom: kodiak: speculative SError risk due to Normal mapping of revoked remote heap
--

commit eae94193b9990051404a938db5815d54041d1867
Author: Jianping Li <jianping.li@oss.qualcomm.com>

arm64: dts: qcom: kodiak: Make the ADSP remote heap no-map

This commit replaces the "reusable" property with "no-map" for the ADSP
remote heap to prevent the kernel from reusing the memory after it has
been assigned to the DSP. It addresses a synchronous external abort that
occurred when the kernel accessed the revoked memory.

Link: https://lore.kernel.org/all/20260423063502.484-1-jianping.li@oss.qualcomm.com/

> diff --git a/arch/arm64/boot/dts/qcom/kodiak.dtsi b/arch/arm64/boot/dts/qcom/kodiak.dtsi
> index f2da3706d5c88..d4a5b02965252 100644
> --- a/arch/arm64/boot/dts/qcom/kodiak.dtsi
> +++ b/arch/arm64/boot/dts/qcom/kodiak.dtsi
> @@ -194,7 +194,7 @@ rmtfs_mem: rmtfs@9c900000 {
>  		adsp_rpc_remote_heap_mem: adsp-rpc-remote-heap {
>  			compatible = "shared-dma-pool";
>  			alloc-ranges = <0x0 0x80000000 0x0 0x80000000>;
> -			reusable;
> +			no-map;

[Severity: High]
Does combining no-map with shared-dma-pool leave a live Normal memory
mapping that can trigger speculative SErrors?

When the DMA framework processes these combined properties,
rmem_dma_device_init() calls dma_init_coherent_memory(), which
unconditionally maps the entire region into vmalloc space:

kernel/dma/coherent.c:dma_init_coherent_memory() {
    ...
    mem_base = memremap(phys_addr, size, MEMREMAP_WC);
    ...
}

Because MEMREMAP_WC creates a Normal Non-Cacheable (MT_NORMAL_NC) mapping,
the CPU can speculatively prefetch from this memory.

Later, when the FastRPC driver assigns the physical memory to the DSP via
qcom_scm_assign_mem(), it revokes HLOS (kernel) access via TrustZone. If the
CPU issues a speculative fetch against the live vmalloc mapping, hitting the
TrustZone protection boundary will cause the interconnect to return an
external abort, triggering an asynchronous SError and crashing the system.

While changing to no-map prevents the linear map from accessing the memory,
does the region need a different compatible string or alternative handling so
the DMA framework doesn't map it back in as Normal memory?

>  			alignment = <0x0 0x400000>;
>  			size = <0x0 0x800000>;
>  		};

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261015071511.977-1-jianping.li@oss.qualcomm.com?part=1

Re: [PATCH v1 1/4] arm64: dts: qcom: kodiak: Make the ADSP remote heap no-map

[Konrad Dybcio]

On 10/15/26 9:15 AM, Jianping Li wrote:
> The ADSP remote heap is declared as a reusable CMA pool. FastRPC
> assigns the entire region to the DSP through qcom_scm_assign_mem()
> during probe without allocating the pages from CMA. Consequently,
> the pages remain available for movable HLOS allocations even after
> HLOS access to the region has been revoked.
> 
> On Kodiak, a synchronous external abort was reported during storage
> testing when the kernel accessed memory within the ADSP remote heap.
> The faulting address was outside the HLOS stage-2 mapping.
> 
> Replace reusable with no-map to prevent the region from being reused
> for normal kernel allocations and exclude it from the kernel's
> standard memory mapping.
> 
> Fixes: 9d7d847ff1c50 ("arm64: dts: qcom: kodiak: avoid EFI overlap for ADSP remote heap")
> Link: https://lore.kernel.org/all/20260423063502.484-1-jianping.li@oss.qualcomm.com/
> Signed-off-by: Jianping Li <jianping.li@oss.qualcomm.com>
> ---

Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>

Konrad

Re: [PATCH v1 2/4] arm64: dts: qcom: glymur: Make the ADSP remote heap no-map

[Konrad Dybcio]

On 10/15/26 9:15 AM, Jianping Li wrote:
> The ADSP remote heap is declared as a reusable shared DMA pool.
> Allowing the kernel to reuse this region is incompatible with handing
> the entire region over to the DSP, as HLOS allocations may then access
> memory for which HLOS no longer has access permissions.
> 
> The same configuration has caused synchronous external aborts on
> other platforms when the kernel accesses pages within the ADSP remote
> heap.
> 
> Replace reusable with no-map to keep the region reserved for the DSP
> and exclude it from the kernel's standard memory mapping.
> 
> Fixes: 67641246eabd0 ("arm64: dts: qcom: glymur: Add memory-region for audio PD")
> Link: https://lore.kernel.org/all/20260701-glymur-audio-v1-1-2c3862d95a09@oss.qualcomm.com/
> Signed-off-by: Jianping Li <jianping.li@oss.qualcomm.com>
> ---

Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>

Konrad

Re: [PATCH v1 3/4] arm64: dts: qcom: sm8250: Make the ADSP remote heap no-map

[Konrad Dybcio]

On 10/15/26 9:15 AM, Jianping Li wrote:
> The ADSP remote heap is declared as a reusable CMA pool. FastRPC
> assigns the entire region to the DSP during probe without allocating
> the pages from CMA. This allows movable HLOS allocations to use pages
> within the region after HLOS access permissions have been revoked,
> potentially causing synchronous external aborts.
> 
> Replace reusable with no-map to prevent the region from being reused
> for normal kernel allocations and exclude it from the kernel's
> standard memory mapping.
> 
> Fixes: 531ce288b6dd4 ("arm64: dts: qcom: sm8250: Add memory-region for audio PD")
> Link: https://lore.kernel.org/all/20260619-sm8250-audio-v1-1-8a76e033e209@oss.qualcomm.com/
> Signed-off-by: Jianping Li <jianping.li@oss.qualcomm.com>
> ---

Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>

Konrad

Re: [PATCH v1 4/4] arm64: dts: qcom: sm8750: Make the ADSP remote heap no-map

[Konrad Dybcio]

On 10/15/26 9:15 AM, Jianping Li wrote:
> The ADSP remote heap is declared as a reusable shared DMA pool.
> Allowing the kernel to reuse this region is incompatible with handing
> the entire region over to the DSP, as HLOS allocations may access
> pages for which HLOS no longer has access permissions.
> 
> The same configuration has caused synchronous external aborts on
> other platforms when the kernel accesses pages within the ADSP remote
> heap.
> 
> Replace reusable with no-map to keep the region reserved for the DSP
> and exclude it from the kernel's standard memory mapping.
> 
> Fixes: 0bcf9ca23a873 ("arm64: dts: qcom: sm8750: add memory node for adsp fastrpc")
> Link: https://lore.kernel.org/all/20251209-sm8750-fastrpc-adsp-v3-1-ccfff49a8af9@linaro.org/
> Signed-off-by: Jianping Li <jianping.li@oss.qualcomm.com>
> ---

Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>

Konrad