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.
CVSS Vector: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H
CVSS Score: 8.8
AV:L - The bug is reached when an s390 KVM guest executes the privileged SIE instruction (B2/14), intercepted through handle_instruction() to kvm_s390_handle_vsie() and setup_apcb10(); that is a local guest/KVM ioctl path with no network, Bluetooth, or USB exposure.
AC:L - An L1 guest that first runs a FORMAT-2 nested SCB (setup_apcb11 fills all 256 APCB bits) and then a FORMAT-0/1 SCB on a recycled vsie page hits setup_apcb10() deterministically; get_vsie_page() reuses pages without clearing crycb, so leftover bits 64-255 persist with no race or uncontrolled memory layout.
PR:L - SIE requires guest supervisor state, i.e. the tenant guest kernel or an unprivileged host kvm-group user running QEMU, not host root; kvm_s390_handle_vsie() has no host capability gate, and user namespaces cannot substitute for this path, so privileges stay Low rather than High.
UI:N - The attacker guest issues SIE and uses the over-permissive shadow APCB itself; vsie page reuse and crycb shadowing run automatically inside KVM with no victim mount, click, or other user action.
S:C - Leftover APCB bits grant a nested guest millicode-enforced access to host AP adapters/domains outside its delegated matrix, crossing the KVM nested-virt and vfio-ap passthrough boundary into another guest's or the host zcrypt authority, equivalent to an IOMMU/device isolation bypass.
C:H - Unauthorized APQNs let the nested guest issue NQAP/DQAP against queues that may now belong to the host zcrypt stack or another tenant, disclosing cryptographic request/response data and key material on those adapters/domains.
I:H - The nested guest can enqueue arbitrary AP requests and change hardware queue state on adapters and domains 64-255 that the current shadow should have cleared, corrupting crypto operations the host believes are exclusive to another consumer.
A:H - With those leftover APQNs the nested guest can PQAP(ZAPQ)-reset or flood shared queues, denying host or sibling-guest crypto services (pkey, secure-key LUKS, openCryptoki) that depend on the same physical adapter/domain.
| Attack Vector |
Local |
Scope |
Changed |
| Attack Complexity |
Low |
Confidentiality Impact |
High |
| Privileges Required |
Low |
Integrity Impact |
High |
| User Interaction |
None |
Availability Impact |
High |
AV:L - The bug is reached when an s390 KVM guest executes the privileged SIE instruction (B2/14), intercepted through handle_instruction() to kvm_s390_handle_vsie() and setup_apcb10(); that is a local guest/KVM ioctl path with no network, Bluetooth, or USB exposure.
AC:L - An L1 guest that first runs a FORMAT-2 nested SCB (setup_apcb11 fills all 256 APCB bits) and then a FORMAT-0/1 SCB on a recycled vsie page hits setup_apcb10() deterministically; get_vsie_page() reuses pages without clearing crycb, so leftover bits 64-255 persist with no race or uncontrolled memory layout.
PR:L - SIE requires guest supervisor state, i.e. the tenant guest kernel or an unprivileged host kvm-group user running QEMU, not host root; kvm_s390_handle_vsie() has no host capability gate, and user namespaces cannot substitute for this path, so privileges stay Low rather than High.
UI:N - The attacker guest issues SIE and uses the over-permissive shadow APCB itself; vsie page reuse and crycb shadowing run automatically inside KVM with no victim mount, click, or other user action.
S:C - Leftover APCB bits grant a nested guest millicode-enforced access to host AP adapters/domains outside its delegated matrix, crossing the KVM nested-virt and vfio-ap passthrough boundary into another guest's or the host zcrypt authority, equivalent to an IOMMU/device isolation bypass.
C:H - Unauthorized APQNs let the nested guest issue NQAP/DQAP against queues that may now belong to the host zcrypt stack or another tenant, disclosing cryptographic request/response data and key material on those adapters/domains.
I:H - The nested guest can enqueue arbitrary AP requests and change hardware queue state on adapters and domains 64-255 that the current shadow should have cleared, corrupting crypto operations the host believes are exclusive to another consumer.
A:H - With those leftover APQNs the nested guest can PQAP(ZAPQ)-reset or flood shared queues, denying host or sibling-guest crypto services (pkey, secure-key LUKS, openCryptoki) that depend on the same physical adapter/domain.
CVSS 3.1