Live › vulnerability › CVE-2026-99124
Go to dashboardThe s390 PCI SCLP error reporting interface does not check that a user-supplied buffer is as long as the report length it declares, so a short write lets an out-of-bounds read pull nearby kernel memory into the report. The leaked data only reaches the privileged SCLP service entity, which can already read that memory, so the flaw is an out-of-bounds read and a malformed-report issue rather than a broad data exposure.
Summary written from the sources below. Check the originals before acting.
First seen by InfraStack 2026-10-28 11:32 UTC. All times on this page are UTC.
Only Linux systems running on IBM Z (s390) hardware with the PCI error reporting path present are in scope; the sources do not name affected kernel version ranges. Systems on other architectures, and s390 hosts without this interface, can skip it.
No product ranges from the sources yet.
Each row is the first time that source carried this signal. The analyst’s rows are its own findings.
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.
This page as .md · .json · in your agent: get_signal("CVE-2026-99124")
NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.