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 <[email protected]> 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/[email protected]?part=1
