Linux Kernel EUVD-2026-86897

Requires a running IBM Z (s390) system with the s390 protected-key AES (paes_s390: ecb/cbc/ctr/xts) or protected-key HMAC (phmac_s390) hardware crypto drivers in use, and a local privileged-enough user able to submit crypto engine requests. The double completion only occurs when a do_one_request callback reaches its error path and returns a negative code after already calling crypto_finalize_hash_request()/crypto_finalize_skcipher_request(); normal success paths are unaffected. Limiting factors: local-only access (AV:L), high attack complexity in reliably hitting the error path (AC:H), some privilege required (PR:L), and the narrow s390 hardware/driver deployment scope.

This is a low-real-world-risk issue despite an NVD CVSS 3.1 base score of 7.0. The vector CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H already reflects local access, high complexity, and required privileges, but its C:H/I:H claims are overstated: the described defect is a double-completion (crypto engine issues a second crypto_request_complete() after the driver already finalized the request) leading to a double-free / DoS, not information disclosure or integrity loss. There is no EPSS score, no CISA KEV listing, and no public POC in the provided data - so no active-exploitation or automation signal exists. Exploitation is further constrained to s390 (IBM Z) systems using the paes protected-key AES or phmac hardware-crypto drivers, and the double completion is reached only on an error path (a callback returning a negative code after explicit finalization). Net: no public exploit identified at time of analysis; this is a crash/DoS reliability fix on a niche platform, not a widespread priority. Note conflict: the 'Information Disclosure' tag and the C:H/I:H metrics are inconsistent with the memory-corruption/DoS nature of the actual bug - treat the confidentiality/integrity impact as unverified.

On an IBM Z (s390) host using the paes or phmac hardware crypto drivers, a local user with access to the crypto API submits requests that drive a do_one_request callback into its error path, where the request is explicitly finalized yet a negative code is returned. The crypto engine then triggers a second completion, causing a double-free and likely kernel crash (DoS). No public exploit code is identified, and reliable triggering depends on hitting the error path.