CVE-2026-99226 in Linux
Summary
by MITRE • 11/02/2026
In the Linux kernel, the following vulnerability has been resolved:
keys: Avoid the owner account dereference in named keyring lookup
Named keyring lookup must keep the storage containing the owner UID alive through the namespace mapping check. find_keyring_by_name() reads keyring->user->uid under keyring_name_lock, but that lock protects the keyring's name entry and allocation, not its separate key_user.
A named session-keyring join can overlap a privileged KEYCTL_CHOWN on another CPU. If the keyring holds the last reference to its old dynamic key_user and the ownership transfer succeeds, the following ordering is possible:
Named join Chown find_keyring_by_name() keyctl_chown_key() read_lock(keyring_name_lock) down_write(key->sem) load old keyring->user replace key->user and key->uid up_write(key->sem) key_put(key) key_user_put(old user): free read old user->uid read_unlock(keyring_name_lock)
Chown neither takes keyring_name_lock nor key_session_mutex, so it can free the old account between the pointer load and the UID read. The lookup then reads freed memory even though the keyring itself is alive.
Use keyring->uid for the mapping check. key_alloc() initializes this inline owner UID and keyctl_chown_key() updates it on chown. The existing name lock keeps its containing keyring allocated throughout the check, so lookup no longer depends on the account's lifetime. This also matches the owner UID used by the permission check.
KASAN report as below:
BUG: KASAN: slab-use-after-free in find_keyring_by_name+0x577/0x5d0 Read of size 4 at addr ffff8881128ae2ec by task keycase/500
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 11/03/2026
The Linux kernel contains a critical use-after-free vulnerability within the named keyring lookup mechanism, specifically in the find_keyring_by_name function. This flaw arises from an incorrect assumption regarding lock coverage and object lifetime management during concurrent operations involving keyrings and user namespaces. The core issue is that while the code attempts to protect access to the keyring's name entry by holding the keyring_name_lock, this mutex does not extend protection to the associated key_user structure which holds the owner UID. Consequently, when a named session-keyring join operation overlaps with a privileged KEYCTL_CHOWN command executed on another CPU core, there exists a race condition that allows the old dynamic key_user object to be freed while it is still being accessed by the lookup routine.
The technical sequence of this vulnerability begins when find_keyring_by_name acquires read access via keyring_name_lock and proceeds to load the pointer to the keyring's user structure. At this precise moment, a concurrent chown operation may execute without holding the same lock or the session mutex. If the targeted keyring holds the final reference count for its previous dynamic key_user, the ownership transfer logic in keyctl_chown_key will successfully replace the user pointer and decrement the old user's reference count to zero. This triggers the immediate deallocation of the old key_user object via key_user_put. Because the lookup operation has already loaded the stale pointer but has not yet read the UID field from that structure, it proceeds to dereference memory that has been returned to the slab allocator for reuse by other kernel allocations.
This race condition results in a classic use-after-free scenario where the kernel reads freed memory to determine the user ID mapping. The impact of this vulnerability is severe as it can lead to arbitrary code execution with kernel privileges, denial of service through system crashes or instability, and potential information disclosure if the reused slab contains sensitive data from previous allocations. The presence of a KASAN report confirming a slab-use-after-free read at find_keyring_by_name validates that this memory corruption path is reachable in real-world scenarios involving concurrent key management operations across different namespaces.
The resolution involves modifying the lookup logic to rely on keyring->uid rather than dereferencing the potentially freed user structure for namespace mapping checks. The key_alloc function initializes this inline owner UID, and keyctl_chown_key updates it during ownership transfers. By using this embedded field, which remains valid as long as the containing keyring is alive and protected by the existing name lock, the vulnerability is eliminated without requiring additional locking overhead or complex synchronization primitives. This approach ensures that the mapping check operates on stable data independent of the dynamic lifetime of the associated user object.
From a standards perspective, this vulnerability corresponds to CWE-416 Use After Free, which describes situations where software continues to use memory after it has been freed leading to unpredictable behavior and security breaches. In terms of attack vectors, this aligns with ATT&CK techniques involving privilege escalation through kernel exploitation, specifically leveraging race conditions in system call handlers to gain unauthorized access or disrupt service integrity. Mitigation strategies include applying the provided kernel patch immediately for affected distributions, ensuring that systems are updated to versions where keyring name lookups utilize the inline UID field instead of dereferencing external user structures during namespace checks. Administrators should also monitor for unusual spikes in key management system calls which might indicate exploitation attempts targeting this specific race condition window.