CVE-2026-64075 in Linux
Summary
by MITRE • 07/19/2026
In the Linux kernel, the following vulnerability has been resolved:
fprobe: Fix unregister_fprobe() 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 synchronize_rcu() in unregister_fprobe().
Note that BPF is OK because fprobe is used as a part of bpf_kprobe_multi_link. This unregisters its fprobe in bpf_kprobe_multi_link_release() and it is deallocated via bpf_kprobe_multi_link_dealloc(), which is invoked from bpf_link_defer_dealloc_rcu_gp() RCU callback.
For BPF, this also introduced unregister_fprobe_async() which does NOT wait for RCU grace priod.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 07/19/2026
The vulnerability resides within the Linux kernel's function probing mechanism, specifically affecting the fprobe functionality that operates in conjunction with the function-graph tracer. This issue stems from a regression introduced in commit 4346ba1604093 which reworked the fprobe implementation to utilize an rcu-hlist for registration purposes. The fundamental flaw occurs during the unregister_fprobe() operation where the code fails to properly synchronize with the RCU grace period before releasing memory resources. This omission creates a race condition that can result in use-after-free conditions when function probes are rapidly unregistered and deallocated, particularly impacting fprobe event handling and sample module implementations.
The technical implementation flaw represents a violation of proper RCU synchronization practices as defined by kernel security standards and best practices for concurrent programming. When the fprobe structure is removed from the rcu-hlist, the absence of synchronize_rcu() call means that the memory associated with the fprobe can be freed before all pending RCU callbacks have completed execution. This creates a window where any ongoing function trace operations or RCU read-side critical sections might attempt to access freed memory, leading to potential system crashes, data corruption, or privilege escalation scenarios. The vulnerability directly maps to CWE-415: Double Free and CWE-416: Use After Free categories within the Common Weakness Enumeration framework.
The operational impact of this vulnerability extends beyond simple kernel stability concerns into potential security implications for systems relying on function tracing capabilities. Attackers could exploit this race condition by creating rapid registration and unregistration sequences of fprobe objects, potentially leading to denial of service conditions or in more sophisticated scenarios, arbitrary code execution within kernel space. The vulnerability affects any system utilizing the function-graph tracer functionality where fprobe events are dynamically created and destroyed, making it particularly concerning for debugging environments, performance monitoring tools, and security analysis frameworks that depend on kernel-level function tracing.
The fix implemented addresses this issue by incorporating synchronize_rcu() into the unregister_fprobe() function, ensuring that all pending RCU callbacks complete before memory deallocation occurs. This approach aligns with established kernel security practices and follows the ATT&CK technique T1059.006 for system commands execution in kernel contexts. The solution maintains backward compatibility while strengthening the synchronization guarantees required for safe concurrent access patterns. Additionally, the implementation includes a specialized unregister_fprobe_async() function for BPF environments that bypasses RCU waiting requirements, though this asynchronous approach is only suitable for contexts where proper RCU handling is managed through alternative mechanisms such as bpf_kprobe_multi_link_release() and bpf_link_defer_dealloc_rcu_gp() callbacks, demonstrating the nuanced approach required for different kernel subsystems.
The remediation strategy reflects a comprehensive understanding of kernel memory management and concurrent programming patterns within the Linux kernel ecosystem. By ensuring proper RCU synchronization during fprobe cleanup operations, the fix prevents potential exploitation vectors while maintaining performance characteristics for legitimate use cases. This vulnerability highlights the critical importance of proper synchronization primitives in kernel-level programming and demonstrates how seemingly minor omissions in concurrent code can create significant security risks. The solution also underscores the importance of comprehensive testing for race conditions in kernel subsystems that utilize RCU mechanisms, particularly when transitioning between different implementation paradigms while maintaining backward compatibility with existing interfaces.