Cloudanix VulnDB

CVE-2026-80708

None

CVSS

—

EPSS

0.2%

Published

Aug 28, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A programming oversight in certain encryption hardware support left secret keys sitting in memory after they should have been erased, creating a chance for attackers to recover them.

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

What it actually does

Internal CPRB buffers used during clear-to-secure key import are not scrubbed after use, leaving clear cryptographic key material in kernel memory that can be recovered through subsequent buffer reuse.

Why it matters to the business

Organizations relying on hardware crypto acceleration on affected Linux systems face increased risk of long-term key compromise, which can undermine encryption of sensitive data and require costly key rotation.

How an attack unfolds

An attacker with local access or the ability to influence memory reuse patterns triggers the vulnerable clear-key import path, then inspects or reuses the same kernel buffers to recover the clear key material that was never zeroized.

How to fix it

Upgrade to a Linux kernel containing the fix that adds the scrub parameter to _ip_cprb_helper(), enables scrubbing for clear-key operations, and explicitly scrubs the random EXOR and CPRB buffers on return from cca_clr2cipherkey().

How to confirm the fix worked

Confirm the running kernel contains the commit that extends _ip_cprb_helper() with the scrub flag and adds the explicit buffer scrubbing in cca_clr2cipherkey(); review source or changelog for the described changes.

Typical attack path

  1. Obtain local execution or memory inspection capability on an s390 Linux system using the zcrypt CCA path
  2. Trigger cca_clr2cipherkey() with attacker-controlled clear key data
  3. Force or wait for reuse of the internal CPRB buffer
  4. Read the retained clear key bytes from the unscrubbed memory region

How to detect it

Review kernel memory dumps or forensic captures for unexpected retention of clear key patterns after CCA import operations; no public exploitation artifacts have been observed.

What your security team should do

  • Prioritize kernel updates on all s390 systems that use zcrypt CCA clear-key import
  • Audit any custom or downstream kernel modules that call _ip_cprb_helper() and ensure scrubbing is enabled for sensitive data
  • Monitor for future backports to supported LTS kernels and schedule testing accordingly

The record

In the Linux kernel, the following vulnerability has been resolved: s390/zcrypt: Fix missing mem scrub at clear key import in cca_clr2cipherkey() The helper function _ip_cprb_helper() uses internal buffer memory for building and processing CPRBs. After use this buffer was never scrubbed which could lead to leaving for example clear key material in memory which could be exposed via tricky reuse of this same memory. Extend the _ip_cprb_helper() function with another parameter 'scrub' used to steer scrubbing of this buffer. So now the caller has the opportunity to decide if scrubbing is needed or not. Extend the clear key to secure key token import process in function cca_clr2cipherkey() to tell the helper function from above to scrub the cprb buffer when the clear key value is part of the request data. Add explicit scrubbing on return from function cca_clr2cipherkey() for the random EXOR buffer and the cprb buffer. Overall this cleans the internal used buffer in case of clear key import to prevent sensitive data to get exposed.

Affected packages

Ecosystem Package Introduced Fixed