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

CVE-2026-64015 Overview

CVE-2026-64015 affects the Linux kernel's security/keys subsystem. The keyring code calls assoc_array_find() inside find_key_to_update() without holding the Read-Copy-Update (RCU) read lock. The assoc_array_gc() routine is designed to remove nodes from the tree and free them after an RCU grace period, which requires callers to hold the RCU read lock during lookup.

Regular key handling masks the issue because the keyring semaphore hides lifetime problems. Persistent key handling uses a different model and exposes the missed RCU section, creating a use-after-free condition on concurrent lookup and garbage-collection paths.

Critical Impact
A local attacker with low privileges can trigger a use-after-free in the kernel keyring, resulting in memory corruption, information disclosure, or local privilege escalation to root.

Affected Products

Linux kernel security/keys subsystem (persistent key handling paths)
Distributions shipping vulnerable upstream kernels prior to the referenced stable commits
Systems using the persistent keyring feature (keyctl get_persistent)

Discovery Timeline

Vulnerability reported by Nicholas Carlini
2026-07-19 - CVE-2026-64015 published to the National Vulnerability Database (NVD)
2026-07-20 - Last updated in NVD database

Technical Details for CVE-2026-64015

Vulnerability Analysis

The Linux kernel keyring implementation stores keys in an associative array structure (assoc_array). Lookups traverse this structure via assoc_array_find(), while assoc_array_gc() prunes and frees nodes asynchronously. The garbage collector defers node frees to after an RCU grace period, relying on readers holding the RCU read lock so that no reader dereferences a node scheduled for release.

In find_key_to_update(), the caller invoked assoc_array_find() without wrapping the call in rcu_read_lock() and rcu_read_unlock(). For most keyring operations, the outer keyring semaphore serialized readers and writers, incidentally preventing the race. Persistent key handling does not take that semaphore in the same way, leaving lookups exposed to concurrent tree edits and freeing.

Root Cause

The defect is a synchronization error in the kernel keyring code path. The assoc_array API contract requires RCU read-side critical sections around lookups so that garbage-collected nodes cannot be freed while a reader still holds a pointer. find_key_to_update() violated that contract. The fix adds the RCU read-side locking that assoc_array was designed for rather than extending the semaphore-based scheme.

Attack Vector

Exploitation requires local access with the ability to invoke keyring system calls such as keyctl() and add_key(). An attacker races persistent keyring lookups against operations that trigger assoc_array_gc() to free tree nodes. Successful timing yields a dangling pointer dereferenced inside the kernel, producing a use-after-free primitive that can be shaped into arbitrary kernel memory read or write, and ultimately privilege escalation.

No public proof-of-concept exploit is currently referenced in the CVE data. Technical details of the fix are available in the kernel commits listed under Linux Kernel Commit 50bb3435 and Linux Kernel Commit 43a1e374.

Detection Methods for CVE-2026-64015

Indicators of Compromise

Kernel oops or panic messages referencing assoc_array_find, find_key_to_update, or keyring_search in dmesg and /var/log/kern.log
Unexpected SIGSEGV or general protection faults originating from processes performing keyctl operations
KASAN (Kernel Address Sanitizer) reports flagging use-after-free in the keys subsystem on instrumented kernels

Detection Strategies

Audit auditd logs for unusual sequences of keyctl syscalls, particularly against the persistent keyring (KEY_SPEC_PERSISTENT_KEYRING)
Monitor for local processes making high-frequency add_key, keyctl_unlink, and persistent keyring lookups that may indicate race exploitation
Correlate kernel crash telemetry with recent user activity to identify attempted exploitation

Monitoring Recommendations

Enable and forward kernel logs to a centralized logging platform for anomaly analysis
Deploy endpoint detection tooling that captures kernel-level events and syscall telemetry on Linux hosts
Track kernel package versions across the fleet to identify unpatched systems susceptible to CVE-2026-64015

How to Mitigate CVE-2026-64015

Immediate Actions Required

Apply vendor-supplied kernel updates that incorporate the upstream fix for security/keys RCU locking
Inventory Linux hosts and prioritize patching multi-user systems and shared workloads where local access is broader
Restrict local shell access on sensitive systems until patches are deployed

Patch Information

The fix adds rcu_read_lock() and rcu_read_unlock() around the assoc_array_find() call in find_key_to_update(). Backports are available in the stable trees via the following commits: Linux Kernel Commit 50bb3435, Linux Kernel Commit 43a1e374, Linux Kernel Commit 4c5d407b, Linux Kernel Commit 5659e692, Linux Kernel Commit 66288dca, and Linux Kernel Commit cefa4265. Update to distribution kernels containing these commits.

Workarounds

Where patching is not immediately possible, disable or restrict use of the persistent keyring by limiting user access to keyctl get_persistent
Apply strict access controls to prevent untrusted local users from executing arbitrary code on affected hosts
Consider mandatory access control policies (SELinux, AppArmor) to constrain processes that interact with the keys subsystem

bash

# Verify running kernel version and check for the fix
uname -r

# Debian/Ubuntu: update kernel packages
sudo apt-get update && sudo apt-get install --only-upgrade linux-image-$(uname -r | sed 's/-generic//')

# RHEL/CentOS/Fedora: update kernel
sudo dnf update kernel

# Reboot into the patched kernel
sudo systemctl reboot