CVE-2026-64075: fprobe: Fix unregister_fprobe() to wait for RCU grace period
In the Linux kernel, the following vulnerability has been resolved:
fprobe: Fix unregisterfprobe() to wait for RCU grace period
Commit 4346ba1604093 ("fprobe: Rewrite fprobe on function-graph tracer") changed fprobe to register struct fprobe to an rcu-hlist, but it forgot to wait for RCU GP. Thus there can be use-after-free if the fprobe is released right after unregistering. This can be happened on fprobe event and sample module code.
To fix this issue, add synchronizercu() in unregisterfprobe().
Note that BPF is OK because fprobe is used as a part of bpfkprobemultilink. This unregisters its fprobe in bpfkprobemultilinkrelease() and it is deallocated via bpfkprobemultilinkdealloc(), which is invoked from bpflinkdeferdeallocrcugp() RCU callback.
For BPF, this also introduced unregisterfprobeasync() which does NOT wait for RCU grace priod.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Compensating control
Ensure the kernel fix is applied so that unregister_fprobe() waits for an RCU grace period by adding synchronize_rcu() in unregister_fprobe().
Event History
Frequently Asked Questions
Which uses are most likely to trigger the issue?
The issue can occur when an fprobe is released immediately after it is unregistered. The description specifically identifies fprobe events and sample module code as affected use cases.
Does the BPF fprobe path require the same remediation?
The BPF path is described as safe because its fprobe is unregistered during bpf_kprobe_multi_link_release() and deallocated later through an RCU callback. The change also adds an asynchronous unregister path for BPF that does not wait for the RCU grace period.
What level of access does exploitation require?
The CVSS vector rates the attack as local with low privileges required and no user interaction. Successful exploitation can affect confidentiality, integrity, and availability.