CVE-2026-89765 in Linux
Summary
by MITRE • 09/11/2026
In the Linux kernel, the following vulnerability has been resolved:
timers/itimer: Zero-init old itimerval before copy to userspace
On native sparc64, struct __kernel_old_timeval contains a four-byte hole after tv_usec because tv_sec is 64-bit while __kernel_suseconds_t is 32-bit. put_itimerval() fills only the named fields in a stack-allocated __kernel_old_itimerval and copies the entire object to userspace, so getitimer() can expose the two padding holes.
Zero-initialize the aggregate before assigning the fields so implicit padding is deterministic before it crosses the user/kernel boundary.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 09/11/2026
The vulnerability identified in the Linux kernel involves an information disclosure flaw within the timer subsystem, specifically affecting the sparc64 architecture. This issue stems from how the kernel handles the serialization of internal timing structures for transmission to user-space applications via system calls such as getitimer. The core technical defect lies in the handling of struct __kernel_old_timeval and its parent structure, itimerval, during the data transfer process between the privileged kernel space and unprivileged user space.
On native sparc64 systems, the definition of struct __kernel_old_timeval includes a structural anomaly due to alignment requirements. Specifically, because tv_sec is defined as a 64-bit integer while tv_usec is a 32-bit signed value, the compiler inserts four bytes of padding or hole between these two fields to maintain proper memory alignment. When the kernel function put_itimerval prepares data for user consumption, it populates only the explicitly named fields within a stack-allocated instance of __kernel_old_itimerval. However, when this structure is copied entirely to userspace using standard copy operations like copy_to_user, the operation includes these uninitialized padding bytes rather than just the meaningful data fields.
This behavior results in an information leak because the four-byte holes contain residual data from previous stack allocations or kernel internal states that were not cleared before use. Consequently, a local user can invoke getitimer and retrieve this sensitive memory content, which may include pointers, process identifiers, or other kernel state information. This constitutes a classic case of uninitialized variable exposure where implicit padding bytes act as conduits for leaking kernel memory contents to untrusted contexts. The vulnerability is classified under CWE-200, which covers Exposure of Sensitive Information to an Unauthorized Actor, and more specifically aligns with CWE-457 regarding the use of Uninitialized Variables in security-critical code paths.
From a threat modeling perspective, this flaw allows for potential reconnaissance activities where attackers can map kernel memory layouts or extract cryptographic keys if they reside on the same stack frame during timer operations. While typically requiring local access to exploit, such leaks contribute significantly to attack chains that aim at privilege escalation by reducing the entropy of kernel address space layout randomization (KASLR) or revealing sensitive state data. In terms of MITRE ATT&CK frameworks, this behavior relates to techniques involving memory disclosure and potentially information gathering for lateral movement or further exploitation within a compromised system environment.
The resolution implemented in the Linux kernel addresses this flaw by enforcing zero-initialization of the entire itimerval aggregate before any specific fields are assigned values. By ensuring that the stack-allocated structure is cleared at its inception, all implicit padding bytes are set to deterministic null values rather than retaining whatever garbage data previously occupied those memory locations. This simple but critical change ensures that when the structure crosses the user/kernel boundary via copy_to_user operations, only valid and sanitized data reaches the application layer, thereby eliminating the vector for information leakage.
To mitigate similar risks in other parts of the kernel or third-party drivers, developers should adhere to strict initialization practices whenever structures containing padding are transmitted across security boundaries. Utilizing designated initializers that explicitly set all members including implicit ones, or employing memset to zero out entire structs before population, is a recommended best practice. Additionally, static analysis tools and compiler warnings such as -Wmissing-field-initializers can help detect these oversights during the development phase, preventing similar vulnerabilities from being introduced into future kernel releases.