Skip to main content
← All vulnerabilities
CVE-2026-99040EUVD-2026-108835GHSA-XFXP-JQFR-M4G5

KEYS: Fix add_key() race with keyring restriction

Published
Last modified
published
Not listed in CISA KEV
Fix
Fixed in 6.6.160, 6.12.113, 6.18.57, 7.2.11
None on Exploit-DB, Metasploit or GitHub

Summary

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.

Timeline

  1. CVE published
  2. First seen by cve.now
  3. Record last updated

Affected versions

  • Linux Linux

    Version range not reported

  • Linux Linux

    4.7

  • KernelLinux

    From 4.7.0 · fixed in 6.6.160; From 6.7.0 · fixed in 6.12.113; From 6.13.0 · fixed in 6.18.57; From 6.19.0 · fixed in 7.2.11

References 8

git.kernel.org