* [PATCH v2 0/2] misc: fastrpc: fix UAF and Oops around SSR teardown
@ 2026-10-22 2:35 Jianping Li
2026-10-22 2:35 ` [PATCH v2 1/2] misc: fastrpc: wake poll-mode waiters on SSR Jianping Li
2026-10-22 2:35 ` [PATCH v2 2/2] misc: fastrpc: drain in-flight invokes before tearing down context banks Jianping Li
0 siblings, 2 replies; 4+ messages in thread
From: Jianping Li @ 2026-10-22 2:35 UTC (permalink / raw)
To: Srinivas Kandagatla, Ekansh Gupta
Cc: Jianping Li, Arnd Bergmann, Greg Kroah-Hartman, Thierry Escande,
linux-arm-msm, dri-devel, linux-kernel, quic_chennak
On Hamoa (X1E80100) IoT EVK the ADSP can restart repeatedly, and every
restart has a chance of taking the kernel down with it:
Unable to handle kernel paging request at virtual address fffffdffc1ffffc0
Internal error: Oops: 0000000096000006
CPU: 5 UID: 0 PID: 2766 Comm: adsprpcd
pc : ___free_pages+0x24/0xe0
Call trace:
___free_pages
__free_pages
__dma_direct_free_pages
dma_direct_free
dma_free_attrs
fastrpc_context_free [fastrpc]
fastrpc_internal_invoke [fastrpc]
fastrpc_device_ioctl [fastrpc]
The faulting address decodes to a struct page for a PFN that has no
vmemmap backing. It comes from dma_free_coherent() being called against
a qcom,fastrpc-compute-cb device that of_platform_depopulate() has
already unbound: with the IOMMU torn down, the call falls through to
dma_direct_free(), which takes the buffer's IOVA for a physical address
and hands the resulting page to the page allocator.
fastrpc_rpmsg_remove() wakes every pending invoke with -EPIPE and then
immediately depopulates the context banks, with no synchronisation in
between, so woken threads race the teardown on their way to
fastrpc_context_free().
The series is ordered so each patch stands on its own:
1/2 makes fastrpc_notify_users() wake poll-mode waiters, which today
keep spinning on a buffer the teardown is about to reclaim.
2/2 counts in-flight invokes and drains them before touching any
channel resource.
Jianping Li (2):
misc: fastrpc: wake poll-mode waiters on SSR
misc: fastrpc: drain in-flight invokes before tearing down context
banks
drivers/misc/fastrpc.c | 61 +++++++++++++++++++++++++++++++++++++++---
1 file changed, 57 insertions(+), 4 deletions(-)
--
2.43.0
^ permalink raw reply [flat|nested] 4+ messages in thread* [PATCH v2 1/2] misc: fastrpc: wake poll-mode waiters on SSR 2026-10-22 2:35 [PATCH v2 0/2] misc: fastrpc: fix UAF and Oops around SSR teardown Jianping Li @ 2026-10-22 2:35 ` Jianping Li 2026-10-22 2:35 ` [PATCH v2 2/2] misc: fastrpc: drain in-flight invokes before tearing down context banks Jianping Li 1 sibling, 0 replies; 4+ messages in thread From: Jianping Li @ 2026-10-22 2:35 UTC (permalink / raw) To: Srinivas Kandagatla, Ekansh Gupta Cc: Jianping Li, Arnd Bergmann, Greg Kroah-Hartman, Thierry Escande, linux-arm-msm, dri-devel, linux-kernel, quic_chennak fastrpc_notify_users() sets ctx->retval to -EPIPE and completes ctx->work for every pending and interrupted context, which is enough to release a thread blocked in fastrpc_wait_for_response(). A thread using polling mode does not wait on that completion. It spins in poll_for_remote_response(), whose exit condition is: (val == FASTRPC_POLL_RESPONSE) || ctx->is_work_done Since the DSP is already down, it will never write FASTRPC_POLL_RESPONSE into the poll address, and is_work_done is left untouched by fastrpc_notify_users(). The thread therefore keeps spinning until FASTRPC_POLL_MAX_TIMEOUT_US expires instead of bailing out immediately. Worse, the poll address lives inside ctx->buf, so a polling thread that has not been told to stop is still reading a buffer that the SSR teardown path is about to reclaim. Set is_work_done along with retval so polling waiters observe the termination on their next iteration, exactly like completion waiters do. Fixes: 96e62cc0a84d ("misc: fastrpc: Add polling mode support for fastRPC driver") Signed-off-by: Jianping Li <jianping.li@oss.qualcomm.com> --- drivers/misc/fastrpc.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/misc/fastrpc.c b/drivers/misc/fastrpc.c index af18ff1992ee..d201f26d8e46 100644 --- a/drivers/misc/fastrpc.c +++ b/drivers/misc/fastrpc.c @@ -2663,6 +2663,7 @@ static void fastrpc_notify_users(struct fastrpc_user *user) spin_lock(&user->lock); list_for_each_entry(ctx, &user->pending, node) { ctx->retval = -EPIPE; + ctx->is_work_done = true; complete(&ctx->work); } spin_unlock(&user->lock); -- 2.43.0 ^ permalink raw reply related [flat|nested] 4+ messages in thread
* [PATCH v2 2/2] misc: fastrpc: drain in-flight invokes before tearing down context banks 2026-10-22 2:35 [PATCH v2 0/2] misc: fastrpc: fix UAF and Oops around SSR teardown Jianping Li 2026-10-22 2:35 ` [PATCH v2 1/2] misc: fastrpc: wake poll-mode waiters on SSR Jianping Li @ 2026-10-22 2:35 ` Jianping Li 2026-10-22 2:53 ` sashiko-bot 1 sibling, 1 reply; 4+ messages in thread From: Jianping Li @ 2026-10-22 2:35 UTC (permalink / raw) To: Srinivas Kandagatla, Ekansh Gupta Cc: Jianping Li, Arnd Bergmann, Greg Kroah-Hartman, Thierry Escande, linux-arm-msm, dri-devel, linux-kernel, quic_chennak fastrpc_rpmsg_remove() clears cctx->rpdev, wakes every pending invoke with -EPIPE through fastrpc_notify_users(), and then goes straight on to of_platform_depopulate() the context bank devices, with nothing synchronising the two: - The only thing stopping new work is the unlocked rpdev check at the top of fastrpc_internal_invoke(). A thread can observe a valid rpdev, get preempted, and resume in the middle of the teardown. - Invokes that were already admitted are woken and head for the bail: label, where fastrpc_context_put() releases ctx->buf through dma_free_coherent(). If the depopulate wins, the call runs against an unbound context bank and falls through to dma_direct_free(), which treats the IOVA as a physical address. Close both windows under cctx->lock: - Add cctx->teardown, set at the start of fastrpc_rpmsg_remove(). fastrpc_internal_invoke() checks it and, in the same critical section, increments cctx->invoke_cnt, so an invoke is either rejected or counted. The count is dropped on every return path. - fastrpc_rpmsg_remove() waits for invoke_cnt to reach zero before clearing rpdev and before touching any other channel resource. The gate lives in fastrpc_internal_invoke() rather than in the ioctl dispatcher so that it also covers fastrpc_device_release() -> fastrpc_release_current_dsp_process(), which sends INIT_RELEASE outside of any ioctl. Teardown is kept separate from rpdev because the two have different lifetimes: the gate must close immediately, whereas rpdev has to stay valid until the admitted invokes have finished rpmsg_send(). Clearing rpdev up front, as the code does today, lets an invoke that was sleeping in an allocation dereference a NULL rpdev: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000358 CPU: 2 UID: 0 PID: 2003 Comm: adsprpcd pc : fastrpc_internal_invoke+0xb40/0x1398 [fastrpc] Call trace: fastrpc_internal_invoke [fastrpc] fastrpc_device_release [fastrpc] __fput __arm64_sys_close The faulting address is the offset of ept within struct rpmsg_device, i.e. the cctx->rpdev->ept dereference in rpmsg_send(). Signed-off-by: Jianping Li <jianping.li@oss.qualcomm.com> --- drivers/misc/fastrpc.c | 60 +++++++++++++++++++++++++++++++++++++++--- 1 file changed, 56 insertions(+), 4 deletions(-) diff --git a/drivers/misc/fastrpc.c b/drivers/misc/fastrpc.c index d201f26d8e46..cffe96a181a2 100644 --- a/drivers/misc/fastrpc.c +++ b/drivers/misc/fastrpc.c @@ -328,6 +328,15 @@ struct fastrpc_channel_ctx { atomic_t ctx_seq; u64 dma_mask; const struct fastrpc_soc_data *soc_data; + /* + * Set once fastrpc_rpmsg_remove() starts tearing the channel down. + * Checked under @lock so that no new invoke can begin afterwards. + */ + atomic_t teardown; + /* Number of in-flight invokes; guarded by @lock */ + int invoke_cnt; + /* Woken whenever @invoke_cnt drops to zero */ + wait_queue_head_t ssr_wait_queue; }; struct fastrpc_device { @@ -1350,12 +1359,23 @@ static int fastrpc_wait_for_completion(struct fastrpc_invoke_ctx *ctx, return fastrpc_wait_for_response(ctx, kernel); } +/* Caller must hold cctx->lock */ +static void fastrpc_channel_update_invoke_cnt(struct fastrpc_channel_ctx *cctx, + bool enter) +{ + if (enter) + cctx->invoke_cnt++; + else if (--cctx->invoke_cnt == 0) + wake_up(&cctx->ssr_wait_queue); +} + static int fastrpc_internal_invoke(struct fastrpc_user *fl, u32 kernel, u32 handle, u32 sc, struct fastrpc_invoke_args *args) { struct fastrpc_invoke_ctx *ctx = NULL; struct fastrpc_buf *buf, *b; + unsigned long flags; int err = 0; @@ -1365,14 +1385,25 @@ static int fastrpc_internal_invoke(struct fastrpc_user *fl, u32 kernel, if (!fl->cctx->rpdev) return -EPIPE; + spin_lock_irqsave(&fl->cctx->lock, flags); + if (atomic_read(&fl->cctx->teardown)) { + spin_unlock_irqrestore(&fl->cctx->lock, flags); + return -EPIPE; + } + fastrpc_channel_update_invoke_cnt(fl->cctx, true); + spin_unlock_irqrestore(&fl->cctx->lock, flags); + if (handle == FASTRPC_INIT_HANDLE && !kernel) { dev_warn_ratelimited(fl->sctx->dev, "user app trying to send a kernel RPC message (%d)\n", handle); - return -EPERM; + err = -EPERM; + goto out; } ctx = fastrpc_context_alloc(fl, kernel, sc, args); - if (IS_ERR(ctx)) - return PTR_ERR(ctx); + if (IS_ERR(ctx)) { + err = PTR_ERR(ctx); + goto out; + } err = fastrpc_get_args(kernel, ctx); if (err) @@ -1428,6 +1459,10 @@ static int fastrpc_internal_invoke(struct fastrpc_user *fl, u32 kernel, if (err) dev_dbg(fl->sctx->dev, "Error: Invoke Failed %d\n", err); +out: + spin_lock_irqsave(&fl->cctx->lock, flags); + fastrpc_channel_update_invoke_cnt(fl->cctx, false); + spin_unlock_irqrestore(&fl->cctx->lock, flags); return err; } @@ -2635,6 +2670,9 @@ static int fastrpc_rpmsg_probe(struct rpmsg_device *rpdev) INIT_LIST_HEAD(&data->invoke_interrupted_mmaps); spin_lock_init(&data->lock); idr_init(&data->ctx_idr); + atomic_set(&data->teardown, 0); + data->invoke_cnt = 0; + init_waitqueue_head(&data->ssr_wait_queue); data->domain_id = domain_id; data->rpdev = rpdev; dev_set_drvdata(&rpdev->dev, data); @@ -2678,11 +2716,25 @@ static void fastrpc_rpmsg_remove(struct rpmsg_device *rpdev) /* No invocations past this point */ spin_lock_irqsave(&cctx->lock, flags); - cctx->rpdev = NULL; + atomic_set(&cctx->teardown, 1); list_for_each_entry(user, &cctx->users, user) fastrpc_notify_users(user); spin_unlock_irqrestore(&cctx->lock, flags); + /* + * Wait for every invoke that was already past the gate to finish. + * They have all just been woken with -EPIPE, and no new one can be + * counted, so this is guaranteed to make progress. + */ + spin_lock_irqsave(&cctx->lock, flags); + while (cctx->invoke_cnt > 0) { + spin_unlock_irqrestore(&cctx->lock, flags); + wait_event(cctx->ssr_wait_queue, cctx->invoke_cnt == 0); + spin_lock_irqsave(&cctx->lock, flags); + } + cctx->rpdev = NULL; + spin_unlock_irqrestore(&cctx->lock, flags); + if (cctx->fdevice) misc_deregister(&cctx->fdevice->miscdev); -- 2.43.0 ^ permalink raw reply related [flat|nested] 4+ messages in thread
* Re: [PATCH v2 2/2] misc: fastrpc: drain in-flight invokes before tearing down context banks 2026-10-22 2:35 ` [PATCH v2 2/2] misc: fastrpc: drain in-flight invokes before tearing down context banks Jianping Li @ 2026-10-22 2:53 ` sashiko-bot 0 siblings, 0 replies; 4+ messages in thread From: sashiko-bot @ 2026-10-22 2:53 UTC (permalink / raw) To: Jianping Li; +Cc: dri-devel Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider: - [High] misc: fastrpc: teardown hang when invoke misses fastrpc_notify_users() - [High] misc: fastrpc: fastrpc_rpmsg_remove() fails to drain all context-bank frees -- commit 5c02fd01b12d73075ac0b237229b9d3b84e331dc Author: Jianping Li <jianping.li@oss.qualcomm.com> misc: fastrpc: drain in-flight invokes before tearing down context banks This commit adds a teardown flag, an in-flight invoke counter, and a wait queue to fastrpc_channel_ctx so that fastrpc_rpmsg_remove() blocks new invocations and waits for active fastrpc_internal_invoke() calls to finish before clearing rpdev and depopulating context bank devices. > diff --git a/drivers/misc/fastrpc.c b/drivers/misc/fastrpc.c > index d201f26d8e463..cffe96a181a2b 100644 > --- a/drivers/misc/fastrpc.c > +++ b/drivers/misc/fastrpc.c [ ... ] > @@ -1365,14 +1385,25 @@ static int fastrpc_internal_invoke(struct fastrpc_user *fl, u32 kernel, > if (!fl->cctx->rpdev) > return -EPIPE; > > + spin_lock_irqsave(&fl->cctx->lock, flags); > + if (atomic_read(&fl->cctx->teardown)) { > + spin_unlock_irqrestore(&fl->cctx->lock, flags); > + return -EPIPE; > + } > + fastrpc_channel_update_invoke_cnt(fl->cctx, true); > + spin_unlock_irqrestore(&fl->cctx->lock, flags); > + > if (handle == FASTRPC_INIT_HANDLE && !kernel) { > dev_warn_ratelimited(fl->sctx->dev, "user app trying to send a kernel RPC message (%d)\n", handle); > - return -EPERM; > + err = -EPERM; > + goto out; > } > > ctx = fastrpc_context_alloc(fl, kernel, sc, args); > - if (IS_ERR(ctx)) > - return PTR_ERR(ctx); > + if (IS_ERR(ctx)) { > + err = PTR_ERR(ctx); > + goto out; > + } [Severity: High] Can fastrpc_rpmsg_remove() hang in wait_event() if it runs after fastrpc_internal_invoke() increments cctx->invoke_cnt, but before fastrpc_context_alloc() adds ctx->node to user->pending? In drivers/misc/fastrpc.c, fastrpc_internal_invoke() checks cctx->teardown, increments cctx->invoke_cnt, and drops fl->cctx->lock before calling fastrpc_context_alloc(): drivers/misc/fastrpc.c:fastrpc_context_alloc() { ... ctx = kzalloc_obj(*ctx); ... init_completion(&ctx->work); INIT_WORK(&ctx->put_work, fastrpc_context_put_wq); spin_lock(&user->lock); list_add_tail(&ctx->node, &user->pending); spin_unlock(&user->lock); ... } If fastrpc_rpmsg_remove() runs on another CPU during that window (for example while fastrpc_context_alloc() sleeps in kzalloc_obj()), it sets cctx->teardown to 1, calls fastrpc_notify_users() once across cctx->users, and then blocks in wait_event(cctx->ssr_wait_queue, cctx->invoke_cnt == 0) with cctx->rpdev still valid. Because ctx->node was not on user->pending when fastrpc_notify_users() ran, ctx->work is never completed with -EPIPE. The invoke thread then finishes fastrpc_context_alloc(), runs fastrpc_get_args(), and calls fastrpc_invoke_send() -> rpmsg_send() without re-checking cctx->teardown. When rpmsg_send() succeeds (such as on a remote channel close, driver unbind, module unload, or when a glink rx intent is cached), fastrpc_wait_for_completion() -> fastrpc_wait_for_response() enters wait_for_completion_interruptible(&ctx->work) for user invokes and sleeps waiting for a remote reply that will never arrive, preventing cctx->invoke_cnt from reaching 0 and leaving fastrpc_rpmsg_remove() stuck in wait_event(). For kernel invokes (or signal-interrupted user invokes), fastrpc_wait_for_completion() returns -ETIMEDOUT after 10 seconds (or -ERESTARTSYS), which skips fastrpc_context_put(ctx) at the bail label while the out label decrements cctx->invoke_cnt to 0, allowing fastrpc_rpmsg_remove() to proceed to of_platform_depopulate() with ctx->buf still allocated on the context bank device. > > err = fastrpc_get_args(kernel, ctx); > if (err) > @@ -1428,6 +1459,10 @@ static int fastrpc_internal_invoke(struct fastrpc_user *fl, u32 kernel, > > if (err) > dev_dbg(fl->sctx->dev, "Error: Invoke Failed %d\n", err); > +out: > + spin_lock_irqsave(&fl->cctx->lock, flags); > + fastrpc_channel_update_invoke_cnt(fl->cctx, false); > + spin_unlock_irqrestore(&fl->cctx->lock, flags); > > return err; > } [ ... ] > @@ -2678,11 +2716,25 @@ static void fastrpc_rpmsg_remove(struct rpmsg_device *rpdev) > > /* No invocations past this point */ > spin_lock_irqsave(&cctx->lock, flags); > - cctx->rpdev = NULL; > + atomic_set(&cctx->teardown, 1); > list_for_each_entry(user, &cctx->users, user) > fastrpc_notify_users(user); > spin_unlock_irqrestore(&cctx->lock, flags); > > + /* > + * Wait for every invoke that was already past the gate to finish. > + * They have all just been woken with -EPIPE, and no new one can be > + * counted, so this is guaranteed to make progress. > + */ > + spin_lock_irqsave(&cctx->lock, flags); > + while (cctx->invoke_cnt > 0) { > + spin_unlock_irqrestore(&cctx->lock, flags); > + wait_event(cctx->ssr_wait_queue, cctx->invoke_cnt == 0); > + spin_lock_irqsave(&cctx->lock, flags); > + } > + cctx->rpdev = NULL; > + spin_unlock_irqrestore(&cctx->lock, flags); [Severity: High] Does waiting only for cctx->invoke_cnt == 0 in fastrpc_rpmsg_remove() still leave context-bank buffers being freed concurrently with or after of_platform_depopulate(&rpdev->dev), or leaked when woken with -EPIPE? There appear to be three paths in drivers/misc/fastrpc.c where ctx->buf or other fastrpc_buf allocations on fl->sctx->dev outlive cctx->invoke_cnt: 1. In fastrpc_invoke_send(), fastrpc_context_get(ctx) takes a second reference on ctx before calling rpmsg_send(): drivers/misc/fastrpc.c:fastrpc_invoke_send() { ... fastrpc_context_get(ctx); ret = rpmsg_send(cctx->rpdev->ept, (void *)msg, sizeof(*msg)); if (ret) fastrpc_context_put(ctx); ... } If fastrpc_rpmsg_callback() runs just before teardown, it completes ctx->work and calls schedule_work(&ctx->put_work) to drop that second reference via fastrpc_context_put_wq(). The woken invoke thread drops its own reference at the bail label and decrements cctx->invoke_cnt to 0 at the out label, allowing fastrpc_rpmsg_remove() to call of_platform_depopulate(&rpdev->dev) while fastrpc_context_put_wq() is still running fastrpc_context_put() -> fastrpc_context_free() -> fastrpc_buf_free(ctx->buf) -> dma_free_coherent() against the unbound context bank. Conversely, if rpmsg_send() succeeded and fastrpc_notify_users() wakes the waiter with -EPIPE before fastrpc_rpmsg_callback() runs, nothing drops the extra reference taken by fastrpc_invoke_send(). At the bail label, list_del(&ctx->node) unlinks ctx from fl->pending and fastrpc_context_put(ctx) only decrements ctx->refcount from 2 to 1, leaking ctx, ctx->buf, ctx->maps, fl, and cctx. 2. If fastrpc_wait_for_completion() returns -ERESTARTSYS or -ETIMEDOUT, the bail label skips fastrpc_context_put(ctx): drivers/misc/fastrpc.c:fastrpc_internal_invoke() { ... bail: if (err != -ERESTARTSYS && err != -ETIMEDOUT) { /* We are done with this compute context */ spin_lock(&fl->lock); list_del(&ctx->node); spin_unlock(&fl->lock); fastrpc_context_put(ctx); } ... } The out label then decrements cctx->invoke_cnt to 0 while ctx remains on fl->pending to be freed later by fastrpc_device_release() -> fastrpc_user_put() -> fastrpc_user_free() after of_platform_depopulate(). 3. Callers of fastrpc_internal_invoke() allocate or free buffers on fl->sctx->dev outside the cctx->invoke_cnt gate: - fastrpc_init_create_process() and fastrpc_req_mmap() call fastrpc_buf_free() on their error paths after fastrpc_internal_invoke() has already decremented cctx->invoke_cnt to 0 and returned -EPIPE. - fastrpc_device_release() calls fastrpc_release_current_dsp_process(fl) (which exits fastrpc_internal_invoke() and drops cctx->invoke_cnt to 0) and only afterwards calls fastrpc_user_put(fl) -> fastrpc_user_free(), which frees fl->init_mem, fl->pending, fl->maps, and fl->mmaps on fl->sctx->dev without blocking fastrpc_rpmsg_remove(). > + > if (cctx->fdevice) > misc_deregister(&cctx->fdevice->miscdev); > -- Sashiko AI review · https://sashiko.dev/#/patchset/20261022023531.465-1-jianping.li@oss.qualcomm.com?part=2 ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2026-10-22 2:53 UTC | newest] Thread overview: 4+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2026-10-22 2:35 [PATCH v2 0/2] misc: fastrpc: fix UAF and Oops around SSR teardown Jianping Li 2026-10-22 2:35 ` [PATCH v2 1/2] misc: fastrpc: wake poll-mode waiters on SSR Jianping Li 2026-10-22 2:35 ` [PATCH v2 2/2] misc: fastrpc: drain in-flight invokes before tearing down context banks Jianping Li 2026-10-22 2:53 ` sashiko-bot
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.