CVE-2026-80543 in Linux
Summary
by MITRE • 08/26/2026
In the Linux kernel, the following vulnerability has been resolved:
s390/zcrypt: Pad trailing CCA or EP11 message with zeros
The both functions xcrb_msg_to_type6cprb_msgx() and xcrb_msg_to_type6_ep11cprb_msgx() copy the user space message into a kernel buffer based on the message length. But on further processing the message is supposed to be 4 byte length adjusted. Thus up to 3 bytes of uninitialized kernel memory are forwarded to further processing steps and may unwanted expose kernel memory to the crypto card firmware.
This patch contains code to pad the gap between user space copied message and message buffer length sent down to further processing of the CCA or EP11 message to zeros.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 08/26/2026
The Linux kernel vulnerability in the s390 zcrypt subsystem involves a critical information disclosure flaw within the cryptographic request handling functions xcrb_msg_to_type6cprb_msgx and xcrb_msg_to_type6_ep11cprb_msgx. These functions are responsible for copying user-space messages into kernel buffers before they are processed by the CCA or EP11 crypto card firmware. The core technical flaw arises from a mismatch between the length of the data copied from user space and the expected fixed-length format required by downstream processing steps, which mandates that messages be aligned to four-byte boundaries. When the incoming message does not perfectly fill this buffer up to the next multiple of four bytes, the remaining portion of the kernel buffer remains uninitialized. Consequently, these gaps contain residual data from previous allocations or operations within the kernel memory space.
This oversight results in an out-of-bounds read condition where up to three bytes of uninitialized kernel memory are inadvertently included in the message payload sent to the hardware cryptographic accelerator. This constitutes a significant security risk as it allows sensitive kernel memory contents, which may include stack variables, pointers, or other confidential data from prior operations, to be exposed to the crypto card firmware. The exposure occurs because the firmware processes the entire buffer length rather than just the valid user-provided portion, effectively leaking internal kernel state through the cryptographic interface. This type of vulnerability is classified under CWE-200 as an Information Exposure and falls within the ATT&CK technique T1537 for Data Exfiltration over Alternative Protocol, specifically leveraging hardware interfaces to bypass standard network or file system monitoring controls.
The operational impact of this flaw extends beyond simple data leakage. By exposing kernel memory contents, an attacker with access to the cryptographic interface could potentially gather information useful for further exploitation attempts, such as defeating address space layout randomization by leaking pointer values or identifying specific kernel structures. Furthermore, depending on how the firmware handles these malformed messages, there is a potential risk of triggering undefined behavior within the hardware processing logic, although the primary concern remains the unauthorized disclosure of privileged memory contents. The vulnerability highlights the importance of strict buffer management and initialization practices when interfacing user-space input with low-level hardware drivers that have direct access to physical resources or firmware interfaces.
To mitigate this vulnerability, the kernel developers implemented a patch that explicitly pads the gap between the copied user-space message and the full message buffer length sent to further processing steps by filling it with zeros. This ensures that no uninitialized memory is transmitted to the crypto card firmware, thereby eliminating the information leak vector. System administrators should ensure their systems are updated with the patched kernel version to close this security gap. Additionally, developers working on similar hardware interface drivers must adhere to strict initialization protocols, ensuring that all buffers used for communication with external devices or firmware are fully zeroed out before being populated with user data and subsequently transmitted. This practice aligns with secure coding standards such as CWE-120 regarding buffer handling and prevents the accidental propagation of sensitive kernel state to untrusted or semi-trusted execution environments like hardware accelerators.