GHSA-7564-V46W-3PMR
Vulnerability from github – Published: 2026-10-18 18:32 – Updated: 2026-10-18 18:32In 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.
{
"affected": [],
"aliases": [
"CVE-2026-98861"
],
"database_specific": {
"cwe_ids": [],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-10-18T16:17:40Z",
"severity": null
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nfprobe: Use guard(rcu_sched_notrace) and check rcu_is_watching()\n\nunregister_fprobe() and unregister_fprobe_async() (used by BPF\nkprobe-multi) rely on standard RCU grace periods (synchronize_rcu()\nand call_rcu()) to wait until in-flight fprobe handlers complete before\nfreeing the fprobe.\n\nHowever, if an fprobe handler executes while RCU is not watching (such\nas in the idle loop or nohz_full extended quiescent states), standard\nRCU does not track preemption-disabled sections. Consequently,\nsynchronize_rcu() does not wait for those executions, which can lead\nto a use-after-free if the fprobe is freed immediately after\nunregistration. Ensure handlers exit early when !rcu_is_watching().\n\nFurthermore, fprobe_fgraph_entry() and fprobe_ftrace_entry() previously\nused guard(rcu)() and rcu_read_lock(), which invoke lockdep on every\nhit under CONFIG_PROVE_LOCKING. This adds overhead and can cause lockdep\nrecursion if probed functions interact with lockdep.\n\nSince rhltable_lookup() and rhl_for_each_entry_rcu() use\nrcu_dereference_all_check() (which checks rcu_read_lock_any_held()),\nholding preemption disabled via rcu_read_lock_sched_notrace() is fully\nvalid and sufficient so long as rcu_is_watching() is true.\n\nDefine and use guard(rcu_sched_notrace)() across fprobe_ftrace_entry(),\nfprobe_fgraph_entry(), and fprobe_return(). This eliminates fast-path\nrcu_read_lock() and lockdep overhead while guaranteeing safe grace\nperiod synchronization.",
"id": "GHSA-7564-v46w-3pmr",
"modified": "2026-10-18T18:32:06Z",
"published": "2026-10-18T18:32:06Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-98861"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a85d0f00671b4d4527317c10ba018680f7d8d673"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/dd4a0d4993633b45470abf6da4ea0ca563402245"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e0a6249190402a28f1e2925a81acf573157d55ef"
}
],
"schema_version": "1.4.0",
"severity": []
}
Drag nodes to arrange them. Double-click a related vulnerability to open it, or a source to visit its link. The Physics button on the left tunes the layout and the simulation; the legend at the bottom left hides or shows nodes by kind and by sighting type.
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
Vulnerability timeline
Sightings and recorded dates, grouped by day · UTC
Loading timeline…
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.