CVE-2026-99245 in Linuxinfo

Summary

by MITRE • 11/03/2026

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().

Once again VulDB remains the best source for vulnerability data.

Analysis

by VulDB Data Team • 11/03/2026

The Linux kernel's key management subsystem contains a critical race condition within the key_reject_and_link function that compromises the integrity of keyring restrictions. This vulnerability arises from an incorrect ordering of synchronization primitives and security checks during the process of linking or rejecting keys into a restricted keyring. Specifically, the restrict_link check is performed before acquiring the keyring semaphore. This timing allows for a race condition where a concurrent execution of keyring_restrict can install new restriction rules while holding the write lock on the same semaphore. Because the initial validation occurs outside the protection of this mutex, it operates against stale or incomplete state information regarding which restrictions are currently active and enforced by the system administrator.

The operational impact of this flaw is significant for systems relying on strict keyring access controls to maintain security boundaries between different users or kernel components. An attacker with sufficient privileges to trigger a race condition could potentially bypass these restrictions, allowing unauthorized keys to be linked into restricted keyrings that should have rejected them based on the newly installed policies. This undermines the fundamental purpose of keyring restrictions, which are designed to limit the types of keys that can be added to specific security contexts, thereby preventing privilege escalation or unauthorized access to sensitive cryptographic material stored within those keyrings.

To resolve this issue, the fix involves reordering the operations within the key_reject_and_link function so that the restrict_link check is performed after acquiring the lock via __key_link_lock. This ensures that the validation logic executes under the protection of the semaphore, guaranteeing consistency with the current state of restrictions enforced by concurrent threads. This approach aligns with the established pattern used in other similar functions such as __key_create_or_update, promoting code consistency and reducing the likelihood of future synchronization errors within the key management subsystem.

From a classification perspective, this vulnerability is categorized under CWE-362, which describes Concurrent Execution using Shared Resource with Improper Synchronization (Race Condition). The failure to properly serialize access to shared state allows for an exploitable window where security controls can be bypassed through timing attacks or concurrent execution paths that exploit the gap between check and enforcement. In terms of adversarial tactics, this relates to ATT&CK technique T1548, specifically Abuse Elevation Control Mechanism, as it involves manipulating system-level access control mechanisms to achieve unauthorized actions. Mitigation strategies primarily involve applying the provided kernel patch which corrects the locking order. System administrators should ensure that their Linux kernels are updated to versions containing this fix and monitor for any unusual activity related to keyring operations if immediate patching is not feasible, although no reliable workaround exists other than updating the software itself.

Responsible

Linux

Reservation

09/25/2026

Disclosure

11/03/2026

Moderation

accepted

EPSS

0.00000

KEV

no

Activities

very low

Sources

Do you need the next level of professionalism?

Upgrade your account now!