On Mon, 13 Apr 2026 17:39:26 +0900 "Masami Hiramatsu (Google)" <[email protected]> wrote:
> Here is the 5th series of patches to fix bugs in fprobe. > The previous version is here. > > https://lore.kernel.org/all/177584108931.388483.11311214679686745474.stgit@devnote2/ > > This version fixes to remove fprobe_hash_node forcibly when fprobe > registration failed [1/3] and skips updating ftrace_ops when fails > to allocate memory in module unloading [2/3]. Hmm, Sashiko pointed out some issues in fprobe, which seems not introduced this series but existing UAF cases. https://sashiko.dev/#/patchset/177606956628.929411.17392736689322577701.stgit%40devnote2 Especially, > In fprobe_return(), the code traverses the fprobe_table which contains > RCU-protected struct fprobe_hlist nodes. These nodes are freed using > kfree_rcu(hlist_array, rcu) in unregister_fprobe_nolock(). > > To safely traverse this RCU-protected list, readers must hold the RCU read > lock. However, fprobe_return() only calls preempt_disable_notrace(). While > disabling preemption acts as an RCU-sched read-side critical section on > non-RT kernels, it does not prevent regular RCU grace periods from > completing on PREEMPT_RT. Thus, kfree_rcu() can free the hlist_array while > fprobe_return() is actively iterating over it. I would like to ask Steve a comment about this. Is fgraph return handler context RCU safe? Thanks, > > Thanks, > --- > > Masami Hiramatsu (Google) (3): > tracing/fprobe: Remove fprobe from hash in failure path > tracing/fprobe: Avoid kcalloc() in rcu_read_lock section > tracing/fprobe: Check the same type fprobe on table as the unregistered > one > > > kernel/trace/fprobe.c | 251 > +++++++++++++++++++++++++++++-------------------- > 1 file changed, 147 insertions(+), 104 deletions(-) > > -- > Masami Hiramatsu (Google) <[email protected]> -- Masami Hiramatsu (Google) <[email protected]>
