mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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

  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®