Answer in brief
CVE-2026-98861 records a Unknown severity vulnerability in fprobe: Use guard(rcu_sched_notrace) and check rcu_is_watching(). The current sources do not mark it as known exploited. The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
A CVSS score is not reported in the current record. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| Linux/Linuxgeneric | >=56b4cfcf1518245493c60fd39c56978f508f1816 <a85d0f00671b4d4527317c10ba018680f7d8d673 || >=657b594b2084b39a4bc6d8493aa2140cb00cea49 <dd4a0d4993633b45470abf6da4ea0ca563402245 || >=657b594b2084b39a4bc6d8493aa2140cb00cea49 <e0a6249190402a28f1e2925a81acf573157d55ef || a4f6a9005ed6cfd360ef2520430927f05f92ffb0 || >=6.18.34 <6.18.56 || >=7.0.11 <7.1 | a85d0f00671b4d4527317c10ba018680f7d8d673, dd4a0d4993633b45470abf6da4ea0ca563402245, e0a6249190402a28f1e2925a81acf573157d55ef, 6.18.56, 7.1 |
| Linux/Linuxgeneric | 7.1 | Not reported |
Published upstream
Oct 18, 2026
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Oct 19, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Oct 18, 2026
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.
Quoted source text, attributed separately from HOL analysis.