KernelScan.io

HIGH Introduced in 3.13

keys Keyring UAF

CVE-2026-64015

CVSS 7.8 / 10.0 NVD

CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

KernelScan AI7.0HIGH

01

In the Linux kernel, the following vulnerability has been resolved: security/keys: fix missed RCU read section on lookup Nicholas Carlini reports that the keyring code calls assoc_array_find() in find_key_to_update() without holding the RCU read lock, while the assoc_array_gc() code really is designed around removing the node from the tree and then freeing it after an RCU grace-period. The regular key handling doesn't see this because holding the keyring semaphore hides any lifetime issues, but the persistent key handling uses a different model. Instead of extending the keyring locking, just do the simple RCU locking that the assoc_array was designed for.

02

Engine v0.4.0

Risk summary

A local unprivileged user can trigger a use-after-free in the kernel keyring subsystem by exploiting the persistent key handling path, which calls assoc_array_find() without holding the RCU read lock. This allows the garbage collector to free a node while it is being traversed. Because the freed object is attacker-reachable kernel heap memory (an assoc_array node), the vulnerability is presumed exploitable for both information disclosure and arbitrary code execution under the industry convention for kernel heap corruption. An immediate kernel panic is also possible.

Affectedsecurity/keys/keyring.c (Linux kernel keyring subsystem)

Vulnerability analysis

The vulnerability is a use-after-free (or access to freed memory) in find_key_to_update() in security/keys/keyring.c. The function calls assoc_array_find() to look up a key in the keyring's associative array without holding the RCU read lock. The assoc_array_gc() garbage collection code is designed to remove nodes from the tree and then free them after an RCU grace period — this design assumes that any concurrent reader holds the RCU read lock to prevent the grace period from completing while the node is in use. For regular key operations, the keyring semaphore is held, which incidentally prevents concurrent GC from freeing the node. However, the persistent key handling path does not hold the keyring semaphore, so there is no protection against concurrent GC freeing the node while assoc_array_find() is traversing it. The fix is a single line: adding guard(rcu)() before the assoc_array_find() call to acquire the RCU read lock for the duration of the lookup, which is exactly what the assoc_array infrastructure was designed to require.

03

BranchIntroducedFixed inPatch commit
6.13.136.1.1754c5d407ba3ff
6.123.136.12.925659e6923cb7
mainline3.137.143a1e3744548
6.183.136.18.3450bb3435a5e6
7.03.137.0.1166288dcadf80
6.63.136.6.142cefa4265b111