CVE-2026-99223: Linux kernel · keys: make keyring indexes independent of kernel addresses
Affects Linux kernelSource GCVE Database
Not known to be exploited.
Data as of 5 Nov 2026, 12:35 UTC
Rated by Threat Radar · CVSS not yet scored by NVD
Thin evidence
One scorer or noneExploitation evidence
Disclosed: evidence found.
CVE published 2 Nov 2026
Detectable: no evidence on record.
No public nuclei template indexed
Weaponized: no evidence on record.
No public exploit code indexed in Metasploit or Exploit-DB
Exploited in the wildExploited: no evidence on record.
Not in CISA KEV and no source reports exploitation
Observed by OffSeq MirageSeen by Mirage: no evidence on record.
No attack traffic recorded by OffSeq Mirage sensors
A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 5 Nov 2026.
What to do
Affected software
| Product | Affected | Fixed in |
|---|---|---|
Ubuntu 26.10linuxpkg:deb/ubuntu/linux?arch=source&distro=stonkingOther threats | Affected
| Fixed in– |
Ubuntu 26.10linux-awspkg:deb/ubuntu/linux-aws?arch=source&distro=stonkingOther threats | Affected
| Fixed in– |
Ubuntu 26.10linux-azurepkg:deb/ubuntu/linux-azure?arch=source&distro=stonkingOther threats | Affected
| Fixed in– |
Ubuntu 26.10linux-azure-fdepkg:deb/ubuntu/linux-azure-fde?arch=source&distro=stonkingOther threats | Affected
| Fixed in– |
Ubuntu 26.10linux-gcppkg:deb/ubuntu/linux-gcp?arch=source&distro=stonkingOther threats | Affected
| Fixed in– |
Ubuntu 26.10linux-oraclepkg:deb/ubuntu/linux-oracle?arch=source&distro=stonkingOther threats | Affected
| Fixed in– |
Check your own hosts for these packages with threat-finder (opens in a new tab), our free open-source scanner.
Description
In the Linux kernel, the following vulnerability has been resolved: keys: make keyring indexes independent of kernel addresses KEYCTL_READ returns the serial numbers in a keyring in associative-array traversal order. The first word of the index is a public, deterministic hash of the type pointer, domain pointer and description. An unprivileged user can therefore insert keys with known descriptions, predict their order for each possible KASLR slide, and recover the kernel image address. On an x86-64 build with 16 MiB alignment, 45 user keys suffice to distinguish the candidate slides. Remove the addresses from the whole index, not just its first hash word. Assign each key type and domain a nonzero 64-bit ID and hash those IDs and the description with a once-initialized SipHash key. Use the full IDs in the later index chunks as well. Truncating or hashing the IDs there would lose the guarantee that distinct type/domain/description tuples have a differing index bit. Allocate IDs lazily since private key types need not be registered. Cache them in the index key so tree walks and copies of an existing index do not need to dereference a type descriptor that may have been unregistered. Keep the 32-bit chunk layout and diff_objects() bit offsets consistent, and retain the separate root slot for keyrings used by recursive search. The key comparison, permissions and userspace data format are unchanged; only the address-dependent in-memory ordering is replaced.
References
- ubuntu.com/security/CVE-2026-99223 (opens in a new tab)
- cve.org/CVERecord?id=CVE-2026-99223 (opens in a new tab)
- git.kernel.org/stable/c/9ebe824d55983c9f063a2c9ef1a08b29812d406f (opens in a new tab)
- git.kernel.org/stable/c/13fc051269d670810d9e314061b61c6dd06116a0 (opens in a new tab)
- git.kernel.org/stable/c/8451d4a4c43127c3b9fdf9fc9ff3fea5539a61f9 (opens in a new tab)
- git.kernel.org/stable/c/9f084ef0beb68091e96ab96f0e95579aac8a77f9 (opens in a new tab)
- git.kernel.org/stable/c/e108b22999edbc6f431466baf6b2016c19b7ed31 (opens in a new tab)
- git.kernel.org/stable/c/84f7c699f8d139f743c7dc11ef41d085690955bb (opens in a new tab)
- git.kernel.org/stable/c/a113eba06bd1183c614d7994864d6e7054140cb9 (opens in a new tab)
- git.kernel.org/stable/c/61ac0585d9f4344d3dfb84b5edff1fee7d532897 (opens in a new tab)