CVE-2026-74567 in Linux
Summary
by MITRE • 08/15/2026
In the Linux kernel, the following vulnerability has been resolved:
keys: fix out-of-bounds read in keyring_get_key_chunk()
For description-level chunks keyring_get_key_chunk() advances the read pointer by level * sizeof(long) past the inline prefix but only bounds-checks the prefix, so a long enough key description is read past its kmemdup(desc, desc_len + 1) allocation. Compute the full byte offset and bounds-check the description against it before reading.
The walk only reaches a description-level chunk when two keys collide through the hash, x, type and domain_tag chunks, so this is reached from an unprivileged add_key(2) with a crafted pair of same-type keys whose index hashes collide; KASAN reports a slab-out-of-bounds read.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 08/15/2026
The vulnerability resides in the Linux kernel's key management subsystem, specifically within the keyring_get_key_chunk() function that handles retrieval of key data chunks. This issue represents a classic out-of-bounds memory access flaw that occurs during the processing of key descriptions within the kernel's security framework. The vulnerability is particularly concerning as it affects the core keyring functionality that manages cryptographic keys and credentials across the system, making it a critical component for maintaining system integrity.
The technical flaw manifests when processing description-level chunks where the function advances the read pointer by level * sizeof(long) past an inline prefix but fails to properly bounds-check against the entire description buffer. The function allocates memory using kmemdup(desc, desc_len + 1) which creates a buffer of exactly desc_len + 1 bytes, yet the subsequent processing calculates a full byte offset without proper validation against this allocated boundary. This discrepancy allows an attacker to read past the allocated memory region, potentially accessing adjacent kernel memory locations and exposing sensitive data.
The operational impact of this vulnerability is significant as it can be exploited through an unprivileged user's add_key(2) system call with carefully crafted inputs. The attack requires creating a collision in the key index hash table by generating two keys of the same type that produce identical hash values for x, type, and domain_tag chunks. This collision mechanism places the attacker in a position to trigger the vulnerable code path through normal kernel operations, making exploitation relatively straightforward from an access perspective. The vulnerability is detected by KASAN (Kernel Address Sanitizer) which reports a slab-out-of-bounds read, indicating that the kernel's memory protection mechanisms have identified the violation.
This vulnerability aligns with CWE-129 Input Validation and CWE-787 Out-of-bounds Write categories, representing a classic buffer overread issue in kernel space. From an ATT&CK framework perspective, this could be categorized under T1547.001 Account Manipulation and T1068 Exploitation for Privilege Escalation, though the current exploit requires only unprivileged access to trigger. The attack vector specifically maps to T1595.001 Network Denial of Service through kernel memory corruption, as it can lead to system instability or information disclosure. The underlying mechanism demonstrates how hash collision attacks can be leveraged in kernel contexts to bypass traditional user-space protections.
The fix for this vulnerability requires computing the full byte offset including all potential padding and alignment considerations before performing any memory reads, ensuring that bounds checking occurs against the complete allocated buffer size rather than just the prefix portion. This approach aligns with secure coding practices recommended by the CERT Secure Coding Standards and follows kernel security best practices established in the Linux kernel documentation for memory management operations. The resolution must maintain backward compatibility while ensuring robust memory access validation to prevent similar issues in other kernel subsystems that handle similar chunked data processing patterns.
The vulnerability highlights the importance of rigorous bounds checking in kernel space operations, particularly when dealing with user-provided data that undergoes hash-based indexing. It demonstrates how seemingly benign hash collisions can be exploited to create memory corruption scenarios in kernel memory management functions. The fix emphasizes the critical need for comprehensive input validation even in trusted kernel contexts where assumptions about data size and layout are common. This issue serves as a reminder of the complex security considerations inherent in kernel development and underscores the necessity of thorough testing including fuzzing and memory safety verification tools before deployment in production environments.
The resolution of this vulnerability contributes to overall system security by preventing potential information disclosure through out-of-bounds reads that could expose kernel memory contents, including sensitive cryptographic material or system state information. The fix ensures that all memory access operations within the keyring subsystem properly validate against allocated buffer boundaries, reducing the attack surface for privilege escalation and denial of service attacks. This improvement aligns with the principle of least privilege and defense in depth strategies essential for maintaining kernel security integrity across modern Linux systems.