Cloudanix VulnDB

CVE-2026-89765

None

CVSS

—

EPSS

0.2%

Published

Sep 11, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

On certain older Sun hardware running Linux, a small amount of internal system memory could accidentally be shown to programs, but the issue is limited and easy to correct with an update.

Exploitation
Local Privilege
Attacker needs
Low Privilege
Complexity
Low
Impact
Data Exposure
Component
OS kernel
Class
Information Disclosure
Remediation
Patch
Effort
Medium
Patch risk
Low

What it actually does

The kernel's put_itimerval() copies a stack-allocated __kernel_old_itimerval without zero-initializing its implicit padding bytes, allowing the two four-byte holes (present on sparc64) to retain prior stack contents when copied to userspace via getitimer().

Why it matters to the business

On affected 64-bit SPARC systems, local processes may read a few bytes of residual kernel memory, creating a narrow information-leakage channel that is unlikely to cause operational disruption but could aid further local attacks.

How an attack unfolds

An attacker with local access on native sparc64 compiles or runs a program that repeatedly invokes getitimer(), inspects the returned struct for non-zero padding values, and correlates those bytes with prior kernel activity to harvest small fragments of stack data.

How to fix it

Upgrade to a kernel containing the zero-initialization change in timers/itimer (the fix ensures the aggregate is zeroed before field assignment). Reboot after installation and verify the patch with kernel version strings or source inspection.

How to confirm the fix worked

Confirm the source tree contains the explicit memset or designated-initializer change before the copy_to_user call in put_itimerval(); on running systems, compare kernel build identifiers against the fixed commit and test getitimer() output for deterministic zero padding on sparc64.

Typical attack path

  1. Obtain local unprivileged shell on sparc64 Linux
  2. Invoke getitimer(ITIMER_REAL, ...) in a tight loop
  3. Examine the two padding fields in the returned itimerval for residual bytes
  4. Correlate leaked bytes with kernel symbols or prior syscalls to map useful data
  5. Use obtained information to craft a follow-on local exploit

How to detect it

On sparc64 systems, search process accounting or syscall audit logs for frequent getitimer() calls from untrusted binaries; inspect memory dumps or strace output for non-zero values in the itimerval padding fields after the call.

What your security team should do

  • Identify all sparc64 Linux instances and schedule kernel updates within normal change windows
  • Add sparc64 getitimer() usage to routine log review until patches are deployed
  • Treat the finding as low-urgency given the narrow architecture scope and low EPSS

The record

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.

Affected packages

Ecosystem Package Introduced Fixed