Description

In the Linux kernel, the following vulnerability has been resolved: s390/zcrypt: Fix buffer over-read in cca_cipher2protkey Add validation of both the actual key buffer size and token length fields in all the cca_check_sec*token() functions. Additionally check in cca_gencipherkey() for possible underflow with returned key size. The CCA token structures contain user-controlled len fields that were used in operations without proper validation against both the actual buffer size and minimum token structure size. An attacker could set this field larger than the actual buffer size, leading to reading beyond buffer boundaries. This may result in a kernel crash or exposure of memory via sending this as part of a request down to the crypto card. Also an attacker could have used a very small len value and thus enforce a buffer under-run which may produce similar effects as a over-read. So now a key must - key buf length must be at least sizeof the token struct - the key len field inside the token must fit into the range of sizeof key token struct ... key buf length

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.1",
  "pubDate": "2026-08-13T15:19:58.093Z",
  "pubdate": "2026-08-13T15:19:58.093Z",
  "executiveSummary": "A buffer over-read and potential underflow vulnerability exists in the Linux kernel s390 zcrypt subsystem, specifically within the cca_cipher2protkey and cca_gencipherkey functions.\nThe vulnerability is classified as an improper input validation and boundary check issue, allowing unverified user-controlled length fields within CCA token structures to be processed without validation against actual buffer boundaries.\nAn attacker capable of interacting with the cryptographic subsystem can exploit this flaw to trigger buffer over-reads or under-runs.\nThe impact of successful exploitation includes kernel crashes leading to denial of service, as well as the potential exposure of sensitive kernel memory contents when leaked data is transmitted in requests to the cryptographic hardware card.\nAffected systems include Linux kernel implementations utilizing the s390 architecture and zcrypt cryptographic device drivers.\nExploitation requires local execution context or access to the zcrypt device interface, with an attacker manipulating internal token structures to bypass structural constraints.",
  "technicalDetails": "The vulnerability resides in the s390 zcrypt subsystem of the Linux kernel, specifically impacting the cca_cipher2protkey function, the cca_check_sec*token validation functions, and the cca_gencipherkey function.\nThe root cause is the absence of rigorous bounds checking on user-controlled length fields embedded within CCA token structures. Historically, these length fields were utilized directly in memory operations without properly verifying them against the actual allocated buffer size or the minimum mandatory size of the token structure.\nAttack flow involves an attacker supplying maliciously crafted CCA token structures with manipulated length parameters. By setting the internal token length field larger than the actual underlying key buffer size, the subsystem reads beyond the legitimate buffer boundaries (buffer over-read). Conversely, an attacker can specify an abnormally small length value to induce boundary underflow conditions.\nIn cca_gencipherkey(), a related vulnerability path involves potential integer underflow resulting from returned key size calculations.\nDuring execution, these invalid lengths are processed by the cca_check_sec*token() functions, which previously failed to enforce that the key buffer length is at least equal to the size of the token structure, and that the internal key length field fits strictly within the range bounded by the token struct size and the total key buffer length.\nWhen the kernel processes these malformed structures, it either dereferences unmapped memory—triggering a kernel panic and subsequent denial of service—or reads adjacent kernel heap memory. This leaked memory can then be appended to requests dispatched downward to the physical crypto card, potentially exposing sensitive data to external interfaces or persistent logs.\nThe vulnerable components include the cca_cipher2protkey, cca_gencipherkey, and cca_check_sec*token functions within the s390 zcrypt driver."
}