The vulnerability in CVE-2026-68451 is a buffer overflow in the s390/zcrypt driver's cca_ecc2protkey() function: a length field from a CCA ECC key token is used directly as a copy size without bounds validation. The patch adds a guard rejecting tokens that exceed available parameter block space — that's the correct immediate fix.
But the critical gap in the CVE description is this: where does the key token originate? In the zcrypt architecture, tokens can come from the IBM cryptographic coprocessor (hardware) or from userspace applications submitting cryptographic requests through ioctl calls. If userspace controls the length field, you have a direct privilege escalation vector. If it's only derived from validated coprocessor responses, the attack surface narrows to malware with firmware access or physical scenarios. The CVSS 7.8 score assumes userspace control — that's the unverified assumption baked into the severity.
On s390x specifically, the copy destination is the CPRB parameter block structure, typically allocated on the kernel stack or heap. Exploitation outcome depends on what surrounds that buffer: adjacent fields like function pointers or size fields for subsequent operations could enable controlled writes, while isolated buffers might yield crash-only behavior. The architecture's supervisor state protections and channel-subsystem I/O model create barriers that don't map directly to x86 exploitation assumptions.
The real concern: zcrypt is the interface to IBM's cryptographic coprocessor that handles encrypted disk I/O, secure boot attestation, and cryptographic key management for the entire mainframe. Compromising it means compromising the trust anchor — the blast radius isn't a conventional kernel privilege escalation, it's potential access to the cryptographic foundations of the system. The CVSS score doesn't capture this scope.
For defenders: verify whether your zcrypt ioctl interface permits unprivileged users to submit custom key tokens. If so, treat this as a priority escalation path. If access is restricted to privileged groups, the practical severity is lower — but any kernel memory corruption reachable from userspace still warrants patching. Check kernel versions and confirm the cca_ecc2protkey() bounds check is present in your deployment.