Cloudanix VulnDB

CVE-2026-99245

None

CVSS

—

EPSS

0.2%

Published

Nov 3, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A timing flaw in the Linux kernel could let an attacker on the same machine slip an unauthorized security key into a protected storage area that should have blocked it.

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

What it actually does

Race condition in key_reject_and_link() allows the restrict_link check to occur before acquiring the keyring semaphore, enabling a concurrent keyring_restrict() call to install a restriction after the check but before the link operation completes.

Why it matters to the business

Attackers may bypass keyring access restrictions, leading to unauthorized key insertion that can undermine cryptographic protections, authentication mechanisms, or secure storage used by system services and applications.

How an attack unfolds

An attacker with local access triggers concurrent operations on a keyring: one thread performs key_reject_and_link() while another installs a restriction via keyring_restrict(). The race allows the link to succeed despite the newly applied restriction, potentially inserting attacker-controlled keys into protected keyrings.

How to fix it

Update to a Linux kernel version containing the fix that moves the restrict_link check after __key_link_lock(). Apply vendor-supplied kernel updates as they become available; no configuration workaround exists.

How to confirm the fix worked

Confirm the installed kernel contains the commit that relocates the restrict_link check inside the semaphore-protected section; review kernel source or changelog for the exact change described in the advisory.

Typical attack path

  1. Obtain local code execution on a Linux system
  2. Identify or create a keyring without an active restriction
  3. Race key_reject_and_link() against keyring_restrict() using multiple threads
  4. Insert a key that would normally be rejected by the restriction
  5. Use the inserted key for further privilege escalation or credential access

How to detect it

Examine kernel audit logs and system call traces for unusual concurrent keyring operations around key_reject_and_link and keyring_restrict; look for processes performing rapid key management calls on the same keyring object.

What your security team should do

  • Prioritize kernel updates on all Linux systems once fixed packages are released
  • Monitor vendor security feeds for backported fixes in supported distributions
  • Limit local user access on systems where keyring restrictions protect sensitive material until patched

The record

In the Linux kernel, the following vulnerability has been resolved: KEYS: Fix key_reject_and_link() race with keyring restriction The restrict_link check in key_reject_and_link() is done before taking the keyring semaphore, racing with a concurrent keyring_restrict() that installs the restriction while holding the semaphore in write mode. Move the check to after __key_link_lock(), so it is done under the semaphore, matching the pattern used in __key_create_or_update().

Affected packages

Ecosystem Package Introduced Fixed