CVE-2026-64015

What it actually does

This is a local Linux kernel race condition in the key management subsystem. The vulnerable path calls assoc_array_find() from find_key_to_update() without holding the required RCU read lock, while assoc_array_gc() may concurrently remove and free the same associative-array node after an RCU grace period. In persistent keyring handling, where the usual keyring semaphore does not fully protect object lifetime, this can create a use-after-free condition in kernel memory. A local authenticated user could potentially trigger memory corruption, causing denial of service or, with reliable exploitation, privilege escalation and compromise of kernel confidentiality, integrity, and availability.

Why it matters to the business

Systems running an affected Linux kernel may allow a low-privileged local user or code already executing on the host to escalate privileges or crash the system. The primary business risk is post-compromise amplification: an attacker who gains a basic foothold through another weakness could use this kernel flaw to obtain root-level control, disable security tooling, access sensitive data, or disrupt critical workloads. It is not known to be exploited in the wild and is not listed in CISA KEV, but the CVSS severity is high because successful exploitation can fully compromise the host.

How an attack unfolds

An attacker first needs local code execution with ordinary user privileges on a vulnerable Linux system. They then exercise the kernel keyring and persistent key handling interfaces in a way that races key lookup/update operations against associative-array garbage collection. Because find_key_to_update() performs an assoc_array_find() without the expected RCU read-side critical section, a concurrent cleanup path may remove and free the underlying object while it is still being accessed. If the race is won, the result may be a kernel crash or a use-after-free primitive. A basic exploit may only cause instability, while a more advanced exploit would attempt to shape kernel heap allocations after the free and redirect the corrupted object access toward privilege escalation.

How to fix it

Apply the Linux kernel update that includes the fix adding the required RCU read-side locking around the affected key lookup path. Because no product-specific affected-version or fixed-version list was provided, use the patched kernel packages from the relevant Linux distribution, appliance vendor, cloud image provider, or upstream stable kernel branch. Prioritize internet-facing multi-user systems, shared compute platforms, developer workstations, CI runners, container hosts, and systems where untrusted users or workloads can execute local code. If immediate patching is not possible, reduce local attack surface by limiting shell access, restricting untrusted workloads, hardening container escape paths, and applying least-privilege controls; however, mitigation is not a substitute for a kernel update. Reboot into the patched kernel after installation, because kernel package installation alone does not remove exposure if the old kernel remains running.

How to confirm the fix worked

Confirm the running kernel, not just the installed package, has been updated to a vendor build that contains the security/keys RCU locking fix. Validate with commands such as uname -a, package-manager queries, and vendor advisory mapping for the deployed distribution. Where source or build metadata is available, confirm the patch touching security/keys and find_key_to_update() is present. After remediation, reboot and verify the active kernel version changed to the fixed build. Optionally run vendor regression tests or keyring-focused workload tests to confirm normal key management behavior. Exposure remains if vulnerable kernels are still bootable and selected by default, so also review bootloader configuration and remove or restrict fallback to vulnerable kernels where operationally appropriate.

Typical attack path

1. Obtain local code execution on a Linux host as an unprivileged or low-privileged user.
2. Interact with Linux keyring or persistent key facilities to create, update, and remove keys repeatedly.
3. Trigger concurrent lookup/update and garbage-collection behavior in the kernel associative-array backing structure.
4. Win the race where assoc_array_find() accesses an object that assoc_array_gc() has removed and freed after an RCU grace period.
5. Cause a kernel panic for denial of service or manipulate the use-after-free condition to gain elevated kernel privileges.

How to detect it

There are no public, CVE-specific exploitation indicators provided, and successful local kernel exploitation may leave limited evidence. Detection should focus on signs of attempted race triggering, kernel instability, and post-exploitation privilege escalation. Review kernel logs from journald, dmesg, /var/log/kern.log, /var/log/messages, crash dumps, and EDR telemetry for use-after-free, RCU, keyring, or associative-array faults. Look for repeated key management activity by unprivileged users, followed by kernel oops/panic events, unexplained reboots, or sudden privilege changes. Correlate any crash involving security/keys, assoc_array_find(), find_key_to_update(), or assoc_array_gc() with user sessions, recently executed binaries, container workloads, cron jobs, and temporary files created shortly before the event. After suspected exploitation, examine whether new privileged users, setuid binaries, kernel modules, persistence mechanisms, disabled security agents, or modified authentication files appeared around the time of the crash or privilege transition.

• BUG: KASAN: use-after-free
• use-after-free in assoc_array_find
• assoc_array_find
• find_key_to_update
• assoc_array_gc
• security/keys
• kernel: BUG: unable to handle kernel paging request
• kernel: general protection fault
• kernel: Oops
• kernel panic
• RCU read-side critical section
• keyring

What your security team should do

• Inventory Linux systems and identify hosts running kernel versions that predate the vendor fix for the security/keys RCU locking issue.
• Patch and reboot high-risk systems first, especially multi-user servers, container hosts, CI/build infrastructure, bastion hosts, and systems running untrusted workloads.
• Monitor for kernel crash, KASAN, oops, panic, or use-after-free messages referencing keyring, assoc_array, find_key_to_update(), or assoc_array_gc().
• Treat suspicious local kernel crashes on vulnerable systems as potential exploitation attempts and preserve volatile evidence before rebooting when feasible.
• Restrict local access and untrusted workload execution until patched, particularly on shared Linux platforms.
• Ensure endpoint telemetry captures privilege changes, suspicious setuid/root shell creation, kernel module loading, and security tool tampering after any unexplained kernel fault.
• Track distribution and appliance vendor advisories because fixed kernel package versions vary by vendor and kernel branch.