CVE-2026-99223
NoneCVSS
—
EPSS
0.2%
Published
Nov 2, 2026
CISA due date
—
Cloudanix analysis
A Linux kernel issue lets attackers learn hidden memory locations used to protect the system, making it easier for them to break in.
- Exploitation
- Local Privilege
- Attacker needs
- Low Privilege
- Complexity
- Low
- Impact
- Data Exposure
- Component
- OS kernel
- Class
- Information Disclosure
- Remediation
- Upgrade
- Effort
- Medium
- Patch risk
- Low
What it actually does
KEYCTL_READ exposes key serial numbers in an order derived from a hash that incorporated kernel pointers for type and domain, allowing an unprivileged process to infer the KASLR slide by inserting keys with chosen descriptions and observing traversal order.
Why it matters to the business
Attackers can bypass kernel address-space layout randomization on Linux systems, increasing the likelihood of successful kernel-level exploits that could lead to full system compromise and data exposure.
How an attack unfolds
An attacker creates a modest number of user keys with predictable descriptions, invokes KEYCTL_READ on a keyring, and correlates the returned serial order against possible KASLR offsets; on x86-64 builds this requires only about 45 keys to uniquely identify the slide and recover the kernel image base.
How to fix it
Upgrade to a Linux kernel containing the fix that replaces pointer-based indexing with lazily allocated 64-bit IDs hashed via SipHash, eliminating address leakage from keyring indexes.
How to confirm the fix worked
Confirm the running kernel is newer than the vulnerable commit; test by creating keys with known descriptions and verifying that KEYCTL_READ order is no longer deterministic across KASLR slides.
Typical attack path
- Create multiple keys in a user keyring using crafted descriptions via keyctl
- Invoke KEYCTL_READ on the keyring to obtain serial numbers in traversal order
- Map observed ordering against candidate KASLR slides to recover the kernel image address
- Leverage the leaked address to bypass KASLR in a subsequent kernel exploit
How to detect it
Review audit logs or eBPF traces for repeated keyctl(KEYCTL_READ) or add_key calls originating from unprivileged UIDs; correlate with processes that subsequently attempt kernel memory access.
What your security team should do
- Prioritize kernel package updates on all Linux hosts within the next maintenance window
- Restrict unprivileged keyctl usage via SELinux or AppArmor where feasible
- Monitor for spikes in key creation or keyctl system calls from untrusted processes
The record
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.
Affected packages
| Ecosystem | Package | Introduced | Fixed |
|---|