CVE-2026-80921 in Linux
Summary
by MITRE • 09/09/2026
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.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 09/09/2026
The vulnerability identified as CVE-2023-something related to KVM on s390 architecture involves an improper handling of cryptographic control block (crycb) state during virtualization operations, specifically within the Virtual SIE (vsie) implementation. In IBM z Systems and Linux kernel environments utilizing KVM for nested virtualization, the hypervisor manages access permissions for hardware devices through specific bits in the AP Control Block. When a guest operating system requests to shadow its cryptographic access configuration from a format0 apcb into another crycb instance, typically during context switches or VM migrations, the code previously failed to clear stale data in the upper range of these control blocks. Specifically, bits 64 through 255 were left unchanged, retaining whatever values existed in the vsie page memory prior to the update operation. This oversight means that if a previous guest had enabled access to specific cryptographic devices via those higher bit positions, and then exited or was suspended, those permissions could persist erroneously when applied to a new or nested guest context.
This technical flaw constitutes an improper privilege assignment scenario where residual state from one execution context leaks into another unrelated context. From a classification perspective, this aligns with CWE-200: Information Exposure and more critically CWE-863: Incorrect Authorization Check because the system fails to properly validate that the requested cryptographic device access is actually permitted for the current guest by relying on stale configuration data rather than explicitly resetting unused bits to zero. The root cause lies in the incomplete initialization of the target crycb structure during the shadowing process, where only a subset of relevant bits are updated while the remainder retain their previous memory contents without explicit sanitization.
The operational impact of this vulnerability is significant for environments running nested virtualization with KVM on s390 platforms. A malicious or compromised guest operating system could potentially exploit this state leakage to gain access to cryptographic hardware devices that have been revoked from its permission set in the host configuration. This unauthorized access allows the guest to perform encryption and decryption operations using hardware accelerators intended for other tenants or higher-privileged contexts, thereby violating isolation boundaries between virtual machines. In multi-tenant cloud environments or shared infrastructure setups, this could lead to data confidentiality breaches if sensitive cryptographic keys are processed through devices that should not be accessible to the specific tenant, potentially facilitating side-channel attacks or unauthorized key management operations.
Furthermore, the ability to access unavailable devices disrupts the principle of least privilege and undermines the security model provided by the hypervisor. Attackers leveraging this flaw could bypass administrative controls designed to restrict cryptographic capabilities based on workload requirements or compliance mandates such as FIPS 140-2/3 which require strict control over cryptographic modules. The persistence of these stale bits means that even after an administrator revokes access rights for a specific device, the guest might continue to utilize it until the underlying memory is overwritten by other operations, creating a window of opportunity for exploitation that persists across VM lifecycle events like suspension, resumption, or migration.
Mitigation strategies primarily involve applying kernel updates provided by Linux distribution vendors that include patches addressing this vsie state management issue. Administrators should ensure their KVM hosts are running patched versions of the linux-kvm package where the code explicitly zeros out bits 64 through 255 in the crycb during shadowing operations to prevent any residual data from influencing subsequent guest contexts. Additionally, organizations employing nested virtualization on s390 architectures should review their cryptographic access control policies and consider implementing additional monitoring for unusual usage patterns of hardware crypto devices that may indicate exploitation attempts. Regular auditing of VM configurations against host-level permissions can also help detect anomalies resulting from such state leakage vulnerabilities before they lead to broader security incidents.