CVE-2026-80921
High · 8.8CVSS
8.8
EPSS
0.1%
Published
Sep 9, 2026
CISA due date
—
Cloudanix analysis
A virtualization bug on IBM Z mainframes could let one virtual machine secretly keep access to cryptographic hardware that the system owner tried to take away.
- Exploitation
- Local Privilege
- Attacker needs
- Low Privilege
- Complexity
- Low
- Impact
- Privilege Gain
- Component
- OS kernel
- Class
- Information Disclosure
- Remediation
- Upgrade
- Effort
- Medium
- Patch risk
- Low
What it actually does
The vulnerability fails to clear stale bits 64-255 in the APCB when shadowing format-0 crypto access controls into the VSIE page, leaving a nested guest with residual permissions to cryptographic devices that have been revoked from its parent.
Why it matters to the business
In s390 virtualized environments an attacker-controlled nested guest may retain unauthorized access to cryptographic hardware, increasing the risk of data exposure, integrity violations, or lateral movement within the host's crypto resources.
How an attack unfolds
An attacker with a compromised or malicious nested guest configures a format-0 APCB, triggers the shadowing path in the VSIE handler, and then uses the retained stale bits to issue crypto operations against devices that the hypervisor has since removed from the guest's access mask.
How to fix it
Apply the upstream kernel commit that zeros the remaining APCB bits during format-0 shadowing; rebuild and deploy the patched KVM module on all s390 hosts running nested virtualization.
How to confirm the fix worked
Confirm the fix by inspecting the VSIE crypto shadowing code path to ensure bits 64-255 are explicitly cleared; run regression tests that revoke crypto devices and verify the nested guest can no longer access them after the change.
Typical attack path
- Obtain code execution inside a nested s390 KVM guest
- Prepare a format-0 APCB containing desired crypto access bits
- Cause the L1 hypervisor to perform VSIE shadowing of the APCB
- Observe that bits 64-255 retain prior values instead of being zeroed
- Issue crypto requests using the stale permissions to reach revoked devices
How to detect it
Review hypervisor logs for unexpected crypto device access attempts from nested guests after device revocation events; correlate with VSIE page allocations and APCB shadowing operations in kernel traces.
What your security team should do
- Prioritize patching s390 KVM hosts that enable nested virtualization
- Audit all s390 systems for nested-guest workloads and restrict crypto device passthrough where possible
- Monitor upstream stable branches for the backported fix and schedule kernel updates within the normal change window
The record
In the Linux kernel, the following vulnerability has been resolved: KVM: s390: vsie: zero stale crypto bits When shadowing crypto access bits from a format0 apcb (crycb 0 or 1), the bits 64..255 are unchanged from whatever is in the vsie page in the crycb and thus in the apcb. This gives a nested guest potential access to a device no longer available. Zero out the remaining bits.
Affected packages
| Ecosystem | Package | Introduced | Fixed |
|---|