Homepage

CVE-2026-99040 Affecting kernel-livepatch-6.12.113-138.209 package, versions <1:1.0-0.amzn2023

Severity

 Recommended
high

Based on Amazon Linux security rating.

Threat Intelligence

EPSS
0.18% (8th percentile)

Do your applications use this vulnerable package?

In a few clicks we can analyze your entire application and see what components are vulnerable in your application, and suggest you quick fixes.

Test your applications
  • Snyk IDSNYK-AMZN2023-KERNELLIVEPATCH612113138209-21811051
  • published29 Oct 2026
  • disclosed23 Oct 2026
Report a new vulnerability Found a mistake?

Introduced: 23 Oct 2026

NewCVE-2026-99040  (opens in a new tab)

How to fix?

Upgrade Amazon-Linux:2023 kernel-livepatch-6.12.113-138.209 to version 1:1.0-0.amzn2023 or higher.
This issue was patched in ALAS2023-2026-3335.

NVD Description

Note: Versions mentioned in the description apply only to the upstream kernel-livepatch-6.12.113-138.209 package and not the kernel-livepatch-6.12.113-138.209 package as distributed by Amazon-Linux. See How to fix? for Amazon-Linux:2023 relevant fixed versions and status.

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.