CVE-2026-98861

In the Linux kernel, the following vulnerability has been resolved:

fprobe: Use guard(rcu sched notrace) and check rcu is watching()

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 in-flight fprobe handlers complete before freeing the fprobe.

However, if an fprobe handler executes while RCU is not watching (such as in the idle loop or nohz full extended quiescent states), standard RCU does not track preemption-disabled sections. Consequently, synchronize rcu() does not wait for those executions, which can lead to a use-after-free if the fprobe is freed immediately after unregistration. Ensure handlers exit early when !rcu is watching().

Furthermore, fprobe fgraph entry() and fprobe ftrace entry() previously used guard(rcu)() and rcu read lock(), which invoke lockdep on every hit under CONFIG PROVE LOCKING. This adds overhead and can cause lockdep recursion if probed functions interact with lockdep.

Since rhltable lookup() and rhl for each entry rcu() use rcu dereference all check() (which checks rcu read lock any held()), holding preemption disabled via rcu read lock sched notrace() is fully valid and sufficient so long as rcu is watching() is true.

Define and use guard(rcu sched notrace)() across fprobe ftrace entry(), fprobe fgraph entry(), and fprobe return(). This eliminates fast-path rcu read lock() and lockdep overhead while guaranteeing safe grace period synchronization.