Linux Kernel EUVD-2026-75098

Exploitation requires all of the following: (1) IBM Z / s390x hardware with hardware AP cryptographic devices (CEX adapters) present and configured; (2) Linux KVM running as the L1 hypervisor with nested virtualization enabled; (3) the vulnerable guest must be launched using a format0 APCB (crycb type 0 or type 1) - not the newer format2/type 3; (4) the vsie shadow page for that guest must contain stale non-zero bits in positions 64-255, which depends on prior page state. Limiting factors: exploitability is restricted to IBM Z hardware deployments (a niche enterprise architecture), requires a nested guest context (L2 inside KVM), and requires stale page state that is not always guaranteed. Exploitation is not possible against standard x86/x86-64 or ARM Linux KVM deployments, nor against flat (non-nested) KVM guests on s390x.

The CVSS 3.1 vector AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H yields 8.8 (High), reflecting a scope-changing local exploit with full CIA impact. The Scope:Changed metric is key: the vulnerability crosses the nested guest boundary to affect the host KVM hypervisor's crypto device allocation enforcement, potentially impacting the host and sibling guests sharing the same AP queues. Despite the high CVSS, real-world risk is substantially constrained by deployment prerequisites: the target system must be IBM Z / s390x hardware, running Linux KVM with nested virtualization enabled, and the specific guest must be launched with a format0 APCB (crycb type 0 or 1) rather than the more capable format2. Organizations running IBM Z for financial or cryptographic workloads - where hardware crypto offload via CEX cards is common - face meaningful risk if nested KVM guests are in use. EPSS data is absent from the input; no KEV listing and no public exploit code exist, suggesting exploitation has not been demonstrated publicly. The risk is best characterized as HIGH for IBM Z environments using nested KVM with hardware crypto delegation, and effectively NEGLIGIBLE outside that deployment model.

An attacker controlling a nested (L2) guest on an IBM Z system attempts to use AP queue indices in the range 64-255 - queues the host hypervisor has not granted. Because the VSIE shadow page retains stale APCB bitmap bits 64-255 from a prior guest's allocation, the nested guest's crypto instructions targeting those queues succeed rather than being intercepted. The attacker can then invoke hardware cryptographic operations (AES, RSA, etc.) using keys loaded on APQNs assigned to other tenants, potentially decrypting or signing data belonging to co-resident workloads. No public exploit code exists at time of analysis.