CVE-2026-80708 Overview
CVE-2026-80708 is an information disclosure vulnerability in the Linux kernel's s390/zcrypt cryptographic subsystem. The flaw affects the cca_clr2cipherkey() function, which handles clear key to secure key token import operations on IBM Z (s390) systems. The internal helper _ip_cprb_helper() allocates buffer memory for building and processing Cryptographic Programming Request Blocks (CPRBs) but fails to scrub this buffer after use. Clear key material can persist in kernel memory and be exposed through subsequent reuse of the same allocation.
Critical Impact
Sensitive cryptographic key material handled during clear-to-secure key import can remain in kernel buffers after operations complete, enabling potential exposure of clear keys to code paths that reuse the same memory region.
Affected Products
- Linux kernel builds on the s390 architecture that include the zcrypt driver
- Systems using IBM Common Cryptographic Architecture (CCA) coprocessors via the s390 zcrypt subsystem
- Kernel branches referenced by the upstream fix commits 01476391, 4e26d0d7, 7dd6e556, 8e1c0def, b453003a, be7ae07f, ebfbb9ac, and fbb04109
Discovery Timeline
- 2026-08-28 - CVE-2026-80708 published to NVD
- 2026-08-28 - Last updated in NVD database
Technical Details for CVE-2026-80708
Vulnerability Analysis
The vulnerability resides in the s390/zcrypt driver path used for importing clear keys and converting them into secure key tokens. The helper _ip_cprb_helper() uses an internal buffer to build and process CPRB structures sent to CCA coprocessors. When the request payload contains clear key material, the buffer holds that material during processing. The original implementation did not zero the buffer before release, leaving plaintext key bytes resident in kernel memory.
The upstream fix extends _ip_cprb_helper() with an additional scrub parameter. Callers can now signal that the CPRB buffer must be wiped after use. The cca_clr2cipherkey() function was updated to pass scrub=true when the request carries clear key data, and it now explicitly scrubs both the random EXOR buffer and the CPRB buffer on return.
Root Cause
The root cause is missing memory sanitization after handling sensitive cryptographic material — a class of information exposure weakness where allocator reuse can surface residual secrets to unrelated kernel code paths. The vulnerable code trusted that buffer lifetimes were self-contained and did not enforce explicit zeroization of sensitive contents.
Attack Vector
Exploitation requires local execution on an s390 system with access to the zcrypt device interfaces. An attacker with the ability to trigger cryptographic operations and subsequently allocate or reuse kernel buffers along the same slab paths could observe residual clear key bytes. The issue does not provide remote code execution or direct privilege escalation, but it undermines the confidentiality guarantee of clear-to-secure key import operations.
Refer to the upstream commits for the exact code changes:
Detection Methods for CVE-2026-80708
Indicators of Compromise
- No specific runtime indicators of compromise are published for this flaw; exploitation leaves no distinctive log signature because it depends on memory residue reads.
- Presence of an unpatched s390/zcrypt module on IBM Z systems performing CCA cipher key imports is the primary risk indicator.
Detection Strategies
- Inventory Linux hosts on s390x architecture and correlate kernel package versions against the fixed commits listed in the kernel.org stable tree references.
- Audit workloads that call CCA clear key import APIs, including applications using libzcrypt or IBM CCA host libraries, to identify systems where clear key material transits kernel buffers.
- Use configuration management tooling to flag kernels lacking the fix.
Monitoring Recommendations
- Monitor access to /dev/z90crypt and related zcrypt device nodes on s390 hosts, restricting access to authorized cryptographic service accounts.
- Track kernel upgrades on mainframe Linux LPARs and z/VM guests to confirm timely deployment of the stable branch fixes.
- Alert on new local processes performing cryptographic key import syscalls on production s390 systems.
How to Mitigate CVE-2026-80708
Immediate Actions Required
- Update affected Linux kernels to a stable release that includes the s390/zcrypt scrub fix from the referenced commits.
- Restrict access to zcrypt device files so that only trusted cryptographic services can invoke clear-to-secure key import operations.
- Prefer secure key workflows that never expose clear key material to the kernel where feasible.
Patch Information
The fix is distributed across multiple stable branches through commits 01476391, 4e26d0d7, 7dd6e556, 8e1c0def, b453003a, be7ae07f, ebfbb9ac, and fbb04109. Each commit extends _ip_cprb_helper() with a scrub parameter and adds explicit memory scrubbing on return from cca_clr2cipherkey() for both the random EXOR buffer and the CPRB buffer. Distribution vendors backport these changes into their supported kernel packages; apply vendor updates once available.
Workarounds
- Limit user-space access to /dev/z90crypt using strict file permissions and namespace isolation until the patched kernel is deployed.
- Where possible, use secure key or protected key workflows rather than clear key import to avoid transiting plaintext key material through kernel buffers.
- Isolate cryptographic workloads onto dedicated LPARs or guests with minimal untrusted local users to reduce the local attack surface.
# Verify running kernel version and zcrypt module status on s390
uname -r
lsmod | grep zcrypt
# Restrict access to zcrypt device nodes
chmod 0660 /dev/z90crypt
chown root:crypto /dev/z90crypt
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

