All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Masami Hiramatsu (Google)" <mhiramat@kernel.org>
To: Steven Rostedt <rostedt@goodmis.org>,
	"Paul E . McKenney" <paulmck@kernel.org>,
	Frederic Weisbecker <frederic@kernel.org>,
	Neeraj Upadhyay <neeraj.upadhyay@kernel.org>
Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
	Josef Bacik <josef@toxicpanda.com>,
	Masami Hiramatsu <mhiramat@kernel.org>,
	linux-kernel@vger.kernel.org, linux-trace-kernel@vger.kernel.org,
	rcu@vger.kernel.org
Subject: [PATCH] fprobe: Protect fprobe_return() with guard(rcu)()
Date: Mon, 28 Sep 2026 09:35:50 +0900	[thread overview]
Message-ID: <179055575009.241711.6358052647499787191.stgit@devnote2> (raw)

Hi,

Here is a bugfix (possible UAF) for fprobe found by Sashiko[1].
[1] https://sashiko.dev/#/bug/linux-e46bcd68-4a56-4f19-a255-e3772980e5e3

I think this fix is a short-term fix to make it safer. Eventually
I would like to replace all guard(rcu)() from fprobe with
preempt_disable_notrace(), because currently it introduces unneeded
overhead to fprobe.

- Introduce new call_rcu_tasks_rude() for async call.
- Add special non-preempt mode flag to rhashtable, which
  uses call_rcu_tasks_rude() instead of call_rcu() 
- Switching to use synchronize_rcu_tasks_rude() for unregistering.
- Replace call_rcu() with call_rcu_tasks_rude() in BPF.

But this is heavy depends on Tasks RCU, so I would like to check
with the RCU maintainers whether this idea aligns with the concept
behind Tasks RCU updates.

Thanks,

---

Masami Hiramatsu (Google) (1):
      fprobe: Protect fprobe_return() with guard(rcu)()


 kernel/trace/fprobe.c |    3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

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

             reply	other threads:[~2026-09-28  0:35 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-28  0:35 Masami Hiramatsu (Google) [this message]
2026-09-28  0:35 ` [PATCH] fprobe: Protect fprobe_return() with guard(rcu)() 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

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=179055575009.241711.6358052647499787191.stgit@devnote2 \
    --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.