Re: [PATCH v11] misc: fastrpc: Allocate entire reserved memory for Audio PD in probe

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 6 potential issue(s) to consider:

New issues:
- [High] DT ABI Breakage: Making the `memory-region` property mandatory for the ADSP domain causes probe failures on older platforms.
- [High] Resource Leak: Memory permissions assigned to the DSP are not restored if `fastrpc_rpmsg_probe` fails, permanently locking the memory region.
- [High] API Contract Violation: `FASTRPC_INIT_CREATE_STATIC` fails for non-ADSP domains because it sends a zero-sized remote heap.
- [Medium] Race Condition: Optimistic state update of `audio_init_mem` leads to spurious initialization failures on concurrent ioctls.

Pre-existing issues:
- [Critical] Use-After-Free: Kernel buffer use-after-free in `fastrpc_req_mmap` on `copy_to_user` failure.
- [High] Resource Leak: SDSP reserved memory permissions are never restored during driver unbind.
--

--- Patch [1]: [PATCH v11] misc: fastrpc: Allocate entire reserved memory for Audio PD in probe ---
commit edbdcebbb8f20e74e19b3ab96b26e3c17ffcc94c
Author: Jianping Li <jianping.li@oss.qualcomm.com>

misc: fastrpc: Allocate entire reserved memory for Audio PD in probe

Allocating and freeing Audio PD memory from userspace is unsafe because
the kernel cannot reliably determine when the DSP has finished using the
memory. This commit allocates the entire Audio PD reserved-memory region
during rpmsg probe and ties its lifetime to the rpmsg channel.

Patch [v10]: https://lore.kernel.org/all/20260716095847.479-1-jianping.li@oss.qualcomm.com/

> diff --git a/drivers/misc/fastrpc.c b/drivers/misc/fastrpc.c
> index dd51d475a74e1..e054e80584a25 100644
> --- a/drivers/misc/fastrpc.c
> +++ b/drivers/misc/fastrpc.c
> @@ -1501,23 +1501,26 @@ static int fastrpc_init_create_static_process(struct fastrpc_user *fl,
>  	args[1].length = inbuf.namelen;
>  	args[1].fd = -1;
>  
> -	pages[0].addr = fl->cctx->remote_heap->dma_addr;
> -	pages[0].size = fl->cctx->remote_heap->size;
> +	/*
> +	 * Audio PD is a static PD and retains the remote heap
> +	 * information across daemon restarts. Therefore only
> +	 * the first attach should provide heap information to
> +	 * DSP. Subsequent attaches reuse the previously
> +	 * initialized memory pool.
> +	 */
> +	spin_lock_irqsave(&cctx->lock, flags);
> +	if (!cctx->audio_init_mem) {
> +		pages[0].addr = cctx->remote_heap_addr;
> +		pages[0].size = cctx->remote_heap_size;

[Severity: High]
Since remote_heap_addr and remote_heap_size are only populated for the
ADSP domain during probe, won't this unconditionally send a zero-sized remote
heap with pageslen = 1 for other static domains like CDSP, SDSP, and MDSP?

Could this break static process creation on non-ADSP domains?

> +		cctx->audio_init_mem = true;

[Severity: Medium]
If this thread is preempted before invoking the DSP, could a concurrent
invocation of fastrpc_init_create_static_process() see audio_init_mem as
true, send a 0-sized remote heap, and reach the DSP first, causing a spurious
initialization failure?

> +		inbuf.pageslen = 1;
> +		sent_heap = true;
> +	} else {
> +		pages[0].addr = 0;
> +		pages[0].size = 0;
> +	}
> +	spin_unlock_irqrestore(&cctx->lock, flags);

[ ... ]

> @@ -2143,20 +2120,6 @@ static int fastrpc_req_mmap(struct fastrpc_user *fl, char __user *argp)
>  	/* let the client know the address to use */
>  	req.vaddrout = rsp_msg.vaddr;
>  
> -	/* Add memory to static PD pool, protection thru hypervisor */
> -	if (req.flags == ADSP_MMAP_REMOTE_HEAP_ADDR && fl->cctx->vmcount) {
> -		u64 src_perms = BIT(QCOM_SCM_VMID_HLOS);
> -
> -		err = qcom_scm_assign_mem(buf->dma_addr, (u64)buf->size,
> -			&src_perms, fl->cctx->vmperms, fl->cctx->vmcount);
> -		if (err) {
> -			dev_err(fl->sctx->dev,
> -				"Failed to assign memory dma_addr %pad size 0x%llx err %d",
> -				&buf->dma_addr, buf->size, err);
> -			goto err_assign;
> -		}
> -	}
> -
>  	spin_lock(&fl->lock);
>  	list_add_tail(&buf->node, &fl->mmaps);
>  	spin_unlock(&fl->lock);

[Severity: Critical]
This is a pre-existing issue, but if the subsequent copy_to_user() fails,
does jumping to err_assign and freeing buf via fastrpc_req_munmap_impl()
leave a freed pointer in the fl->mmaps list since list_del(&buf->node)
isn't called?

Could unprivileged userspace exploit this use-after-free by intentionally
causing a fault here?

[ ... ]

> @@ -2584,12 +2547,22 @@ static int fastrpc_rpmsg_probe(struct rpmsg_device *rpdev)
>  		}
>  	}
>  
> -	if (domain_id == SDSP_DOMAIN_ID) {
> +	if (domain_id == SDSP_DOMAIN_ID || domain_id == ADSP_DOMAIN_ID) {
>  		struct resource res;
>  		u64 src_perms;
>  
>  		err = of_reserved_mem_region_to_resource(rdev->of_node, 0, &res);
> +
> +		if (err && domain_id == ADSP_DOMAIN_ID) {
> +			dev_err(rdev, "missing mandatory remote heap memory-region\n");
> +			goto err_free_data;
> +		}

[Severity: High]
Does making the memory-region property mandatory for the ADSP domain break
device tree ABI compatibility for older platforms that do not define this
property in their fastrpc node?

> +
>  		if (!err) {
> +			if (domain_id == ADSP_DOMAIN_ID) {
> +				data->remote_heap_addr = res.start;
> +				data->remote_heap_size = resource_size(&res);
> +			}
>  			src_perms = BIT(QCOM_SCM_VMID_HLOS);
>  
>  			err = qcom_scm_assign_mem(res.start, resource_size(&res), &src_perms,
>  								data->vmperms, data->vmcount);
>  			if (err)
>  				goto err_free_data;
>  		}

[Severity: High]
If a subsequent step in fastrpc_rpmsg_probe() fails and the code jumps
to err_free_data, are the memory permissions assigned to the DSP by
qcom_scm_assign_mem() permanently leaked since HLOS access is never restored
in the error path?

[ ... ]

> @@ -2698,8 +2671,24 @@ static void fastrpc_rpmsg_remove(struct rpmsg_device *rpdev)
>  	list_for_each_entry_safe(buf, b, &cctx->invoke_interrupted_mmaps, node)
>  		list_del(&buf->node);
>  
> -	if (cctx->remote_heap)
> -		fastrpc_buf_free(cctx->remote_heap);
> +	if (cctx->remote_heap_size && cctx->vmcount) {
> +		u64 src_perms = 0;
> +		struct qcom_scm_vmperm dst_perms;
> +
> +		for (i = 0; i < cctx->vmcount; i++)
> +			src_perms |= BIT(cctx->vmperms[i].vmid);
> +
> +		dst_perms.vmid = QCOM_SCM_VMID_HLOS;
> +		dst_perms.perm = QCOM_SCM_PERM_RWX;
> +
> +		err = qcom_scm_assign_mem(cctx->remote_heap_addr,
> +					  cctx->remote_heap_size, &src_perms,
> +					  &dst_perms, 1);

[Severity: High]
This is a pre-existing issue, but since remote_heap_size is only populated
for the ADSP domain, does this skip the restore step for the SDSP domain?

Could this lead to a permanent leak of the SDSP reserved memory region in
TrustZone when the driver is unbound?

> +		if (err)
> +			dev_err(&rpdev->dev,
> +				"Failed to assign memory back to HLOS: addr %pa size %#llx err %d\n",
> +				&cctx->remote_heap_addr, cctx->remote_heap_size, err);
> +	}
>  
>  	of_platform_depopulate(&rpdev->dev);

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