Cloudanix VulnDB

CVE-2026-99226

None

CVSS

—

EPSS

0.2%

Published

Nov 2, 2026

CISA due date

—

Cloudanix analysis

Next patch cycle SSVC: Track

A timing flaw in the Linux kernel's handling of security keys could let a local user crash the system or potentially take control of it.

Exploitation
Local Privilege
Attacker needs
Low Privilege
Complexity
Moderate
Impact
Privilege Gain
Component
OS kernel
Class
Use After Free
Remediation
Patch
Effort
Medium
Patch risk
Low

What it actually does

Use-after-free in find_keyring_by_name() where a concurrent KEYCTL_CHOWN can free the key_user structure holding the owner UID after the pointer is loaded under keyring_name_lock but before the UID is read, allowing the lookup to dereference freed memory.

Why it matters to the business

Linux systems may experience kernel crashes, memory corruption, or potential local privilege escalation when unprivileged users perform rapid keyring operations, leading to denial of service or full system compromise on affected kernels.

How an attack unfolds

An attacker on a multi-CPU Linux system races a named session keyring join against a privileged chown operation on another keyring that holds the last reference to its key_user; the timing frees the user structure between the load and the UID read, resulting in a slab use-after-free that can be turned into arbitrary read or escalation.

How to fix it

Upgrade to a Linux kernel containing the fix that uses the inline keyring->uid field instead of dereferencing the key_user for the namespace mapping check; apply vendor-supplied kernel updates as soon as available.

How to confirm the fix worked

Verify the running kernel contains the commit that replaces the keyring->user->uid read with keyring->uid under keyring_name_lock; confirm absence of KASAN slab-use-after-free reports referencing find_keyring_by_name after applying the update.

Typical attack path

  1. Obtain unprivileged local access on a multi-CPU Linux host
  2. Create or reference a named keyring that will be the target of lookup
  3. Trigger concurrent KEYCTL_CHOWN on a related keyring while performing find_keyring_by_name via keyctl or session join
  4. Exploit the freed key_user structure for memory corruption or information leak

How to detect it

Search kernel logs and KASAN output for slab-use-after-free messages citing find_keyring_by_name; inspect crash dumps for key_user dereferences during keyctl_chown_key or session keyring joins.

  • BUG: KASAN: slab-use-after-free in find_keyring_by_name
  • Read of size 4 at addr .* by task .*key.*
  • find_keyring_by_name+0x577/0x5d0

What your security team should do

  • Prioritize kernel updates on all multi-user and multi-CPU Linux systems within the next patch cycle
  • Monitor for KASAN or slab corruption reports involving keyring functions
  • Restrict unprivileged keyctl usage via SELinux or AppArmor where feasible until patched

The record

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

Affected packages

Ecosystem Package Introduced Fixed