All of lore.kernel.org
 help / color / mirror / Atom feed
From: Masami Hiramatsu (Google) <mhiramat@kernel.org>
To: paulmck@kernel.org
Cc: Steven Rostedt <rostedt@goodmis.org>,
	Frederic Weisbecker <frederic@kernel.org>,
	Neeraj Upadhyay <neeraj.upadhyay@kernel.org>,
	Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
	Josef Bacik <josef@toxicpanda.com>,
	linux-kernel@vger.kernel.org, linux-trace-kernel@vger.kernel.org,
	rcu@vger.kernel.org
Subject: Re: [PATCH] fprobe: Protect fprobe_return() with guard(rcu)()
Date: Tue, 29 Sep 2026 09:13:40 +0900	[thread overview]
Message-ID: <20260929091340.2a3832ebd5089cb30dfb83f0@kernel.org> (raw)
In-Reply-To: <1c2a58be-0c8d-45b1-a803-85480e976e11@paulmck-laptop>

On Mon, 28 Sep 2026 09:10:10 -0700
"Paul E. McKenney" <paulmck@kernel.org> wrote:

> On Mon, Sep 28, 2026 at 09:35:59AM +0900, Masami Hiramatsu (Google) wrote:
> > From: Masami Hiramatsu (Google) <mhiramat@kernel.org>
> > 
> > In fprobe_return(), the shadow-stack iteration and exit_handler
> > invocations were protected by preempt_disable_notrace().
> > However, unregister_fprobe() and unregister_fprobe_async() (used
> > by BPF kprobe-multi) rely on standard RCU grace periods (synchronize_rcu()
> > and call_rcu()) to wait until the fprobe is no longer in use before
> > freeing it.
> > 
> > In preemptible kernels (CONFIG_PREEMPT_RCU=y), standard RCU grace
> > periods do not wait for pure preempt_disable_notrace() critical
> > sections. Consequently, an unregistered fprobe may be freed while
> > a concurrent CPU executing fprobe_return() is still running
> > fp->exit_handler(), causing a use-after-free.
> 
> Actually, standard RCU grace periods wait for preemption-disabled regions
> of code regardless of kernel configuration.  So if the original code
> below was broken, that indicates a bug in RCU.

Thanks for pointing, this was my mistake. Sorry about that.
And I still think we need a fix to add rcu_is_watching() check.

Thank you,

> 
> So do you have a reproducer for this?
> 
> 							Thanx, Paul
> 
> > To resolve this, protect fprobe_return() with guard(rcu)() matching
> > fprobe_fgraph_entry(). This ensures both synchronous unregister_fprobe()
> > and asynchronous unregister_fprobe_async() safely wait for in-flight
> > exit_handlers to complete via standard RCU grace periods.
> > 
> > Reported-by: Sashiko <sashiko-bot@kernel.org>
> > Closes: https://sashiko.dev/#/bug/linux-e46bcd68-4a56-4f19-a255-e3772980e5e3
> > Fixes: 657b594b2084 ("fprobe: Fix unregister_fprobe() to wait for RCU grace period")
> > Cc: stable@vger.kernel.org
> > Assisted-by: LLM
> > Signed-off-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
> > ---
> >  kernel/trace/fprobe.c |    3 +--
> >  1 file changed, 1 insertion(+), 2 deletions(-)
> > 
> > diff --git a/kernel/trace/fprobe.c b/kernel/trace/fprobe.c
> > index 9f2d98181779..c3e1580bc648 100644
> > --- a/kernel/trace/fprobe.c
> > +++ b/kernel/trace/fprobe.c
> > @@ -671,7 +671,7 @@ static void fprobe_return(struct ftrace_graph_ret *trace,
> >  	size_words = SIZE_IN_LONG(size);
> >  	ret_ip = ftrace_regs_get_instruction_pointer(fregs);
> >  
> > -	preempt_disable_notrace();
> > +	guard(rcu)();
> >  
> >  	curr = 0;
> >  	while (size_words > curr) {
> > @@ -687,7 +687,6 @@ static void fprobe_return(struct ftrace_graph_ret *trace,
> >  		}
> >  		curr += size;
> >  	}
> > -	preempt_enable_notrace();
> >  }
> >  NOKPROBE_SYMBOL(fprobe_return);
> >  
> > 


-- 
Masami Hiramatsu (Google) <mhiramat@kernel.org>

      reply	other threads:[~2026-09-29  0:13 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-28  0:35 [PATCH] fprobe: Protect fprobe_return() with guard(rcu)() Masami Hiramatsu (Google)
2026-09-28  0:35 ` Masami Hiramatsu (Google)
2026-09-28  0:51   ` sashiko-bot
2026-09-28 12:22     ` Masami Hiramatsu
2026-09-29 19:39       ` Steven Rostedt
2026-09-29 23:30         ` Masami Hiramatsu
2026-09-28 16:10   ` Paul E. McKenney
2026-09-29  0:13     ` Masami Hiramatsu [this message]

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=20260929091340.2a3832ebd5089cb30dfb83f0@kernel.org \
    --to=mhiramat@kernel.org \
    --cc=frederic@kernel.org \
    --cc=josef@toxicpanda.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-trace-kernel@vger.kernel.org \
    --cc=mathieu.desnoyers@efficios.com \
    --cc=neeraj.upadhyay@kernel.org \
    --cc=paulmck@kernel.org \
    --cc=rcu@vger.kernel.org \
    --cc=rostedt@goodmis.org \
    /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 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.