Re: [PATCH v2] misc: fastrpc: avoid duplicate DMA mappings in fastrpc_create_maps()

[sashiko-bot@kernel.org]

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

New issues:
- [Critical] A data race when clearing `mmap->flags` in `fastrpc_put_args()` allows multiple concurrent threads to double-free a shared DMA handle map.
- [High] A time-of-check to time-of-use (TOCTOU) race condition in `fastrpc_get_args()` leads to a Use-After-Free read of a `fastrpc_map` object.
- [High] Bypassing reference counting for shared DMA handles leads to premature destruction of IOMMU mappings and DSP SMMU faults.

Pre-existing issues:
- [Critical] `fastrpc_req_mem_unmap_impl()` accesses and frees a map without holding a reference or lock, leading to Use-After-Free and Double-Free on concurrent unmap requests.
- [Critical] A compromised or malicious DSP can force the host kernel to copy arbitrary kernel memory to userspace by modifying the shared `rpra` buffer.
--

--- Patch [1]: [PATCH v2] misc: fastrpc: avoid duplicate DMA mappings in fastrpc_create_maps() ---
commit e27fd6a362ab035d376548e127d0d378dd957590
Author: Jianping Li <jianping.li@oss.qualcomm.com>

misc: fastrpc: avoid duplicate DMA mappings in fastrpc_create_maps()

This patch attempts to prevent duplicate DMA mappings by skipping extra
references for DMA handles and tagging them with FASTRPC_MAP_DMA_HANDLE.
It adds re-validation of borrowed maps in fastrpc_get_args() and modifies
fastrpc_put_args() to only release maps tagged with this new flag.

> diff --git a/drivers/misc/fastrpc.c b/drivers/misc/fastrpc.c
> index f3a49384586d1..12c82072236b2 100644
> --- a/drivers/misc/fastrpc.c
> +++ b/drivers/misc/fastrpc.c

[ ... ]

> @@ -999,23 +1001,25 @@ static int fastrpc_create_maps(struct fastrpc_invoke_ctx *ctx)
>  	int i, err;
>  
>  	for (i = 0; i < ctx->nscalars; ++i) {
> +		bool take_ref = i < ctx->nbufs;
> +		int mflags = 0;
>  
>  		if (ctx->args[i].fd == 0 || ctx->args[i].fd == -1 ||
>  		    ctx->args[i].length == 0)
>  			continue;
>  
> -		if (i < ctx->nbufs)
> -			err = fastrpc_map_create(ctx->fl, ctx->args[i].fd,
> -				 ctx->args[i].length, ctx->args[i].attr, &ctx->maps[i]);
> -		else
> -			err = fastrpc_map_attach(ctx->fl, ctx->args[i].fd,
> -				 ctx->args[i].length, ctx->args[i].attr, &ctx->maps[i]);
> +		/* Set the DMA handle mapping flag for DMA handles */
> +		if (i >= ctx->nbufs)
> +			mflags = FASTRPC_MAP_DMA_HANDLE;
> +
> +		err = fastrpc_map_create(ctx->fl, ctx->args[i].fd, ctx->args[i].length,
> +					 ctx->args[i].attr, &ctx->maps[i], take_ref, mflags);

[Severity: High]
Does bypassing reference counting (take_ref = false) for shared DMA handles
lead to premature destruction of IOMMU mappings in
drivers/misc/fastrpc.c:fastrpc_create_maps()?

If two concurrent threads pass the same fd to the DSP, they share the map with
a single reference count. When the first thread finishes and frees the map,
could this destroy the IOMMU mapping while the DSP is still actively using it
for the second thread, causing an SMMU fault?

>  		if (err) {
>  			dev_err(dev, "Error Creating map %d\n", err);
>  			return -EINVAL;
>  		}
>  	}

[ ... ]

> @@ -1143,6 +1147,16 @@ static int fastrpc_get_args(u32 kernel, struct fastrpc_invoke_ctx *ctx)
>  		list[i].num = ctx->args[i].length ? 1 : 0;
>  		list[i].pgidx = i;
>  		if (ctx->maps[i]) {
> +			/* It is possible that map is created with
> +			 * mflags FASTRPC_MAP_DMA_HANDLE and take_ref
> +			 * is false. Check if map still exists or is
> +			 * being freed as take_ref is false
> +			 */
> +			if (fastrpc_map_lookup(ctx->fl, ctx->args[i].fd,
> +					       &ctx->maps[i], false)) {
> +				ctx->maps[i] = NULL;
> +				return -EINVAL;
> +			}
>  			pages[i].addr = ctx->maps[i]->dma_addr;

[Severity: High]
Is there a time-of-check to time-of-use race condition here in
drivers/misc/fastrpc.c:fastrpc_get_args()?

Because fastrpc_map_lookup() is called with take_ref = false, it sets
ctx->maps[i] inside a spinlock but returns without incrementing the reference
count. If a concurrent thread drops the final reference and frees the map
immediately after the lock is released, does the subsequent dereference of
ctx->maps[i]->dma_addr result in a use-after-free read?

>  			pages[i].size = ctx->maps[i]->size;
>  		}

[ ... ]

In drivers/misc/fastrpc.c:fastrpc_put_args(), earlier in the function:

	for (i = inbufs; i < ctx->nbufs; ++i) {
		if (!ctx->maps[i]) {
			void *src = (void *)(uintptr_t)rpra[i].buf.pv;
			void *dst = (void *)(uintptr_t)ctx->args[i].ptr;
			u64 len = rpra[i].buf.len;

			if (!kernel) {
				if (copy_to_user((void __user *)dst, src, len)) {

[Severity: Critical]
This is a pre-existing issue, but can a compromised DSP force the host kernel
to copy arbitrary kernel memory to userspace here?

The src pointer (rpra[i].buf.pv) and len are read directly from DSP-modifiable
shared memory without validation. If the kernel does not verify that these
values match the original bounds allocated for the RPC, could the DSP overwrite
them to point to arbitrary kernel memory addresses and leak sensitive data?

> @@ -1199,8 +1213,13 @@ static int fastrpc_put_args(struct fastrpc_invoke_ctx *ctx,
>  	for (i = 0; i < FASTRPC_MAX_FDLIST; i++) {
>  		if (!fdlist[i])
>  			break;
> -		if (!fastrpc_map_lookup(fl, (int)fdlist[i], &mmap, false))
> +		/* Validate the map flags for DMA handles and skip freeing map if invalid */
> +		if (!fastrpc_map_lookup(fl, (int)fdlist[i], &mmap, false) &&
> +		    mmap->flags == FASTRPC_MAP_DMA_HANDLE) {
> +			/* Allow DMA handle maps to free only once */
> +			mmap->flags = 0;

[Severity: Critical]
Does clearing mmap->flags here introduce a data race in
drivers/misc/fastrpc.c:fastrpc_put_args()?

The test and subsequent modification of mmap->flags are performed completely
locklessly. If two concurrent threads process the same file descriptor returned
by the DSP, could both threads evaluate the flag check as true simultaneously,
clear the flag, and call fastrpc_map_put(mmap), resulting in a double-free?

>  			fastrpc_map_put(mmap);
> +		}
>  	}
>  
>  	return ret;

[ ... ]

In drivers/misc/fastrpc.c:fastrpc_req_mem_unmap_impl():

	spin_lock(&fl->lock);
	list_for_each_entry_safe(iter, m, &fl->maps, node) {
		if ((req->fd < 0 || iter->fd == req->fd) && (iter->raddr == req->vaddr)) {
			map = iter;
			break;
		}
	}
	spin_unlock(&fl->lock);
	...
	fastrpc_map_put(map);

[Severity: Critical]
This is a pre-existing issue, but does fastrpc_req_mem_unmap_impl() access and
free a map without holding a reference or lock?

When searching for a map under fl->lock, the function breaks out of the loop
and drops the lock without incrementing the reference count via fastrpc_map_get().
If two concurrent threads call the unmap ioctl for the same virtual address,
could both threads find the map, drop the lock, and subsequently call
fastrpc_map_put() causing a double-free and use-after-free?

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