Skip to main content
CVE Vulnerability Database
Vulnerability Database/CVE-2026-64075

CVE-2026-64075: Linux Kernel Use-After-Free Vulnerability

CVE-2026-64075 is a use-after-free vulnerability in the Linux kernel fprobe mechanism that can occur when an fprobe is released immediately after unregistering. This article covers technical details, affected systems, and mitigation.

Updated:

CVE-2026-64075 Overview

CVE-2026-64075 is a use-after-free vulnerability in the Linux kernel's fprobe subsystem. The flaw exists because unregister_fprobe() fails to wait for a Read-Copy-Update (RCU) grace period after removing a struct fprobe from an RCU hash list. If the fprobe structure is freed immediately after unregistration, concurrent readers holding RCU references can access memory that has already been released.

The regression was introduced by commit 4346ba1604093 ("fprobe: Rewrite fprobe on function-graph tracer"), which converted fprobe registration to an rcu-hlist without adding the corresponding synchronization. The fix adds synchronize_rcu() to unregister_fprobe() and introduces unregister_fprobe_async() for callers such as BPF that already defer deallocation through RCU callbacks.

Critical Impact

Local users capable of triggering fprobe unregistration through tracing interfaces or sample modules may cause kernel memory corruption or arbitrary kernel-mode read/write via use-after-free.

Affected Products

  • Linux kernel versions containing commit 4346ba1604093 ("fprobe: Rewrite fprobe on function-graph tracer")
  • Distributions shipping the affected fprobe implementation prior to backports of commits 56b4cfc, 657b594, and a4f6a90
  • Systems exposing fprobe events (/sys/kernel/tracing/dynamic_events) or loading fprobe sample modules

Discovery Timeline

  • 2026-07-19 - CVE-2026-64075 published to the National Vulnerability Database
  • 2026-07-19 - Last updated in NVD database

Technical Details for CVE-2026-64075

Vulnerability Analysis

The fprobe (function probe) facility allows kernel tracers to attach probes to kernel functions via the function-graph tracer. After the rewrite referenced in commit 4346ba1604093, active fprobe structures are tracked on an RCU-protected hash list (rcu-hlist). Readers walk this list inside RCU read-side critical sections without acquiring a lock.

The unregister_fprobe() path removed the node from the list but did not call synchronize_rcu() before returning to its caller. Callers routinely free the struct fprobe immediately after unregistration. Any concurrent reader still traversing the list can dereference a freed object, producing a classic use-after-free condition ([CWE-416]).

The bug is reachable through the fprobe tracing event interface and through the in-tree fprobe sample module. BPF is unaffected because bpf_kprobe_multi_link_dealloc() runs inside a bpf_link_defer_dealloc_rcu_gp() RCU callback, which already guarantees a grace period before freeing memory.

Root Cause

The root cause is a missing RCU synchronization primitive. Removing a node from an RCU list must be followed by synchronize_rcu() or call_rcu() before the memory can be reclaimed. The rewrite adopted RCU-list semantics for readers but retained synchronous free semantics for writers, breaking the RCU contract.

Attack Vector

Exploitation requires the ability to register and rapidly unregister fprobe instances. On systems where unprivileged users cannot access tracing interfaces, the attack surface is limited to local privileged contexts or code paths that programmatically invoke fprobe registration. A racing thread executing an fprobe callback can observe a freed struct fprobe, leading to kernel memory disclosure, denial of service via kernel panic, or potential privilege escalation if the freed slab is reallocated with attacker-controlled data.

No public proof-of-concept exploit code is available for CVE-2026-64075. Technical details are documented in the upstream fix commits 56b4cfcf1518245493c60fd39c56978f508f1816, 657b594b2084b39a4bc6d8493aa2140cb00cea49, and a4f6a9005ed6cfd360ef2520430927f05f92ffb0.

Detection Methods for CVE-2026-64075

Indicators of Compromise

  • Kernel oops or panic logs referencing unregister_fprobe, fprobe_handler, or rethook after tracing activity
  • KASAN reports flagging use-after-free reads in fprobe callback paths
  • Unexpected loads of fprobe sample modules such as fprobe_example.ko on production hosts

Detection Strategies

  • Enable CONFIG_KASAN on test kernels to surface use-after-free access in the fprobe hot path
  • Audit uses of /sys/kernel/tracing/dynamic_events and /sys/kernel/tracing/events/fprobes/ for creation and deletion patterns consistent with race exploitation
  • Compare running kernel commit hashes against the fixed commits 56b4cfc, 657b594, and a4f6a90 to identify unpatched hosts

Monitoring Recommendations

  • Forward dmesg and kernel crash telemetry to a centralized logging pipeline for pattern analysis
  • Monitor loading of tracing-related kernel modules and configuration writes to the tracing filesystem
  • Track privileged process activity that opens tracing_on, dynamic_events, or kprobe_events in short time windows

How to Mitigate CVE-2026-64075

Immediate Actions Required

  • Apply the upstream stable kernel updates containing commits 56b4cfcf1518245493c60fd39c56978f508f1816, 657b594b2084b39a4bc6d8493aa2140cb00cea49, and a4f6a9005ed6cfd360ef2520430927f05f92ffb0
  • Restrict access to /sys/kernel/tracing/ and /sys/kernel/debug/tracing/ to root or a dedicated tracing group
  • Remove or blacklist fprobe sample modules from production images

Patch Information

The fix adds synchronize_rcu() inside unregister_fprobe() so that all in-flight RCU readers complete before the caller may free the struct fprobe. A new helper, unregister_fprobe_async(), preserves the previous non-blocking behavior for callers that already defer deallocation through their own RCU callback, such as BPF's bpf_kprobe_multi_link release path. Patches are available in the mainline Linux tree via Kernel Git Commit 56b4cfc, Kernel Git Commit 657b594, and Kernel Git Commit a4f6a90.

Workarounds

  • Disable fprobe events by setting CONFIG_FPROBE_EVENTS=n and rebuilding the kernel where feasible
  • Ensure tracefs and debugfs are mounted with restrictive permissions (mode=0700) and unmounted on hosts that do not require tracing
  • Prevent loading of the fprobe sample module by adding blacklist fprobe_example to /etc/modprobe.d/
bash
# Configuration example: restrict tracefs and blacklist fprobe sample module
mount -o remount,mode=0700 /sys/kernel/tracing
echo 'blacklist fprobe_example' > /etc/modprobe.d/disable-fprobe-sample.conf
chmod 700 /sys/kernel/debug/tracing 2>/dev/null || true

Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

Default Legacy - Prefooter | Experience the World’s Most Advanced Cybersecurity Platform

Experience the Most Advanced Cybersecurity Platform

See how the world’s most intelligent, autonomous cybersecurity platform can protect your organization today and into the future.