Cloudanix VulnDB

CVE-2026-99124

None

CVSS

—

EPSS

0.2%

Published

Oct 28, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A bug in the Linux kernel on IBM Z systems could let a local program accidentally pull internal kernel memory into an error report sent to a privileged component.

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

Out-of-bounds kernel memory read in report_error_write() when user-supplied SCLP report length exceeds the validated buffer size, copying up to ~4 KB of uninitialized data from beyond the kernfs allocation into the report.

Why it matters to the business

Limited risk of kernel memory disclosure to privileged entities on s390 systems; requires prompt patching to prevent malformed reports and maintain kernel integrity across Linux deployments.

How an attack unfolds

An attacker with local access supplies a short buffer claiming a larger report length; the missing length validation causes the kernel to read past the allocated buffer and embed prior kernel contents into the SCLP error report delivered to the privileged recipient.

How to fix it

Apply the upstream kernel patch that adds proper validation of report->length against the actual buffer size before copying data; rebuild and deploy the fixed kernel on all s390 systems.

How to confirm the fix worked

Inspect the patched report_error_write() implementation to confirm an explicit bounds check exists between the claimed length and the allocated buffer; attempt reproduction with a deliberately short buffer to verify the request is now rejected.

Typical attack path

  1. Obtain local unprivileged access on an s390 Linux system
  2. Invoke the SCLP error reporting path via a userspace write with undersized buffer and inflated length field
  3. Trigger report_error_write() to perform the out-of-bounds read
  4. Receive the resulting SCLP report containing leaked kernel memory

How to detect it

Search kernel logs and audit trails for unusual SCLP report submissions containing non-zero or unexpected data patterns beyond normal error headers; review any userspace processes writing to SCLP error paths.

What your security team should do

  • Prioritize kernel update on all s390 Linux hosts within the next maintenance window
  • Monitor upstream stable branches for the official backport
  • Restrict unprivileged access to SCLP interfaces where operationally feasible

The record

In the Linux kernel, the following vulnerability has been resolved: s390/pci: Fix leak of uninitialized kernel data in SCLP report While report_error_write() checks that the provided buffer is at least as large as the header struct, but not that it is large enough to contain the report with the length claimed by report->length. If user-space provides a short buffer, meaning a larger report->length than the actually written payload, up to around 4K of kernel data from past the kmalloc(len + 1) sized buffer allocated in kernfs_fop_write_iter() will leak into the SCLP report. However, as the entity processing the SCLP is privileged and able to access at least the page including the report, this does not leak data that entity could not access but it is still an out of bounds read and a malformed error report that should be rejected.

Affected packages

Ecosystem Package Introduced Fixed