From: Greg KH <gregkh@linuxfoundation.org>
To: bo cao <treebacker@foxmail.com>
Cc: srini@kernel.org, linux-kernel@vger.kernel.org, stable@vger.kernel.org
Subject: Re: [PATCH 1/2] misc: fastrpc: pin invoke context at glink response lookup
Date: Fri, 30 Oct 2026 09:39:29 +0100 [thread overview]
Message-ID: <2026103041-handrail-civic-a9fa@gregkh> (raw)
In-Reply-To: <tencent_18454D1845AB2A759EA9AB3ABE52E67AE205@qq.com>
On Fri, Oct 30, 2026 at 04:19:55PM +0800, bo cao wrote:
> fastrpc_rpmsg_callback() looks up the invoke context under cctx->lock
> but then uses it after dropping the lock, including the ctxid read in
> the sequence validation itself, ctx->retval, complete() and
> schedule_work().
>
> The final kref_put() happens outside the lock (in the invoking
> thread's bail path or in the put_work worker) and
> fastrpc_context_free() removes the context from ctx_idr only after
> releasing its maps and DMA buffer, so a context found in the IDR may
> already have a zero refcount with free in progress:
>
> callback freeing thread
> -------- --------------
> lock; idr_find() -> ctx; unlock
> (refcount already 0; free is
> releasing maps and buf)
> lock; idr_remove(); unlock
> kfree(ctx)
> read ctx->ctxid for the seq
> check -- use after free
>
> Take a reference on the context inside the same critical section as
> the idr_find() lookup and run the sequence validation there too;
> drop the reference after scheduling the worker (or when the response
> is dropped). kref_get_unless_zero() is required because the IDR may
> still hold a context whose refcount has already reached zero while
> fastrpc_context_free() is running.
>
> Fixes: c68cfb718c8f ("misc: fastrpc: Add support for context Invoke method")
> Cc: stable@vger.kernel.org
> Signed-off-by: bo cao <treebacker@foxmail.com>
> ---
> drivers/misc/fastrpc.c | 24 ++++++++++++++++--------
> 1 file changed, 16 insertions(+), 8 deletions(-)
These two messages are not "threaded" properly, sent as 2 separate
emails. Is that intentional? It breaks our tooling :(
Please use something like 'git send-email' or 'b4' for sending patches
out, that's what those tools were written for.
thanks,
greg k-h
next prev parent reply other threads:[~2026-10-30 8:39 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-30 8:19 bo cao
2026-10-30 8:39 ` Greg KH [this message]
2026-10-30 8:55 ` fastrpc: use-after-free of fastrpc_invoke_ctx on duplicate glink responses in fastrpc_rpmsg_callback() bo cao
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2026103041-handrail-civic-a9fa@gregkh \
--to=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=srini@kernel.org \
--cc=stable@vger.kernel.org \
--cc=treebacker@foxmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®