Cloudanix VulnDB

CVE-2026-99040

None

CVSS

—

EPSS

0.2%

Published

Oct 23, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A timing flaw in the Linux kernel can let a local user add security keys even when restrictions are supposed to block them.

Exploitation
Local Privilege
Attacker needs
Low Privilege
Complexity
Moderate
Impact
Privilege Gain
Component
OS kernel
Class
Race Condition
Remediation
Patch
Effort
Medium
Patch risk
Low

What it actually does

Race condition in __key_create_or_update allows a writer with keyring write permission to observe a stale NULL restrict_link snapshot, bypass a subsequently installed reject-all restriction, and successfully link a key.

Why it matters to the business

Local attackers can evade keyring access controls, enabling unauthorized key insertion that may facilitate privilege escalation or persistent access on affected systems.

How an attack unfolds

An attacker with write access to a destination keyring races against restriction installation by keyring_restrict; the stale snapshot permits add_key to succeed and link a key despite the reject-all policy.

How to fix it

Upgrade to a patched kernel that moves the restrict_link read after __key_link_lock and __key_link_begin so the check is serialized under the keyring semaphore.

How to confirm the fix worked

Verify the kernel source contains the reordered restrict_link read after locking; re-execute the published concurrency test to confirm all add_key calls now fail with -EPERM under the same ordering.

Typical attack path

  1. Obtain write permission on the target keyring
  2. Trigger or time a restriction installation concurrently
  3. Invoke add_key to perform the link operation using the stale snapshot
  4. Use the successfully linked key to escalate privileges or maintain access

How to detect it

Review kernel audit logs and keyctl traces for successful key links immediately following restriction changes on the same keyring; correlate with processes holding write access.

What your security team should do

  • Apply the upstream fix or distribution kernel update as soon as available
  • Audit systems for local users with keyring write access and tighten permissions
  • Enable kernel audit logging for keyring and add_key operations

The record

In the Linux kernel, the following vulnerability has been resolved: KEYS: Fix add_key() race with keyring restriction __key_create_or_update() snapshots keyring->restrict_link before taking the destination keyring's semaphore. keyring_restrict() installs a restriction while holding that semaphore. This allows a writer to observe no restriction, wait for the keyring owner to install a reject-all restriction and return successfully, and then link a key using the stale NULL snapshot. The writer only needs write permission on the destination keyring. Move the restrict_link read after __key_link_lock() and __key_link_begin(). The read and the subsequent restriction check are then serialized with restriction installation by keyring->sem. The race was reproduced on v7.2.8 in 19 executions where restriction installation returned before the link completed. All 19 linked the key despite the reject-all restriction. With this change, 312 executions reached the same ordering and every add_key() call failed with -EPERM. The issue was found by manual concurrency analysis assisted by AI-based analysis and independently verified with a QEMU reproducer and kernel instrumentation.

Affected packages

Ecosystem Package Introduced Fixed