* [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.