In the Linux kernel, the following vulnerability has been resolved:
s390/vfio-ap: Fix hot-unplug skipped when last AP adapter or domain removed
The vfio_ap_mdev_hot_unplug_cfg() function uses the return value of
bitmap_andnot() to determine whether the guest APCB needs to be updated.
However, bitmap_andnot() returns false when the resulting destination
bitmap is empty. This means that if the only adapter, domain or control
domain assigned to an mdev is removed from the host's AP configuration,
the bit is correctly cleared from the shadow APCB, but bitmap_andnot()
returns false because the result is an empty bitmap. Consequently,
do_hotplug remains 0 and vfio_ap_mdev_update_guest_apcb() is never called,
leaving the KVM guest with stale hardware access to the unplugged AP
devices.
Fix this by replacing the bitmap_andnot() return value check with
bitmap_intersects() to determine whether the shadow APCB actually
overlaps with the removal mask. If there is an intersection, call
bitmap_andnot() solely for its side effect of clearing the bits, then
unconditionally set do_hotplug to trigger the guest APCB update.
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 a host AP QCI change is picked up by ap_scan_bus() and vfio_ap_on_cfg_changed() calls vfio_ap_mdev_hot_unplug_cfg(), which fails to push the cleared shadow APCB into a local KVM guest via kvm_arch_crypto_set_masks(); that is a local sysfs/firmware/KVM path with no network, Bluetooth, or USB exposure.
AC:L - Removing the last adapter, domain, or control domain assigned to a vfio-ap mdev from the host AP configuration empties the shadow APCB so bitmap_andnot() returns false and vfio_ap_mdev_update_guest_apcb() is skipped every time; a single-adapter guest plus sysfs config=0 or HMC unplug is the designed hot-unplug path, with no race or uncontrolled memory layout.
PR:L - The leftover millicode APCB is exercised by the tenant KVM guest or the unprivileged host kvm-group QEMU process that already holds the vfio-ap mdev, not by host root; kvm_arch_crypto_set_masks() is the revocation the guest then bypasses, and user namespaces cannot create that mdev, so privileges stay Low rather than High.
UI:N - Once the last assigned adapter or domain is removed from host QCI, the guest CRYCB still contains the old bits and the guest can issue NQAP/DQAP/PQAP immediately; no separate victim mount, click, or other user action is required.
S:C - The skipped kvm_arch_crypto_set_masks() leaves the guest with millicode-enforced access to AP adapters and domains the host has unplugged, crossing the KVM/vfio-ap passthrough isolation boundary into hardware that may now belong to the host zcrypt stack or another consumer, equivalent to an IOMMU/device isolation bypass.
C:H - Unauthorized APQNs let the guest dequeue AP replies (DQAP) from queues the host believes were unplugged, disclosing cryptographic request/response data and key material on those adapters and domains.
I:H - The guest can enqueue arbitrary AP requests (NQAP) and change hardware queue state on adapters and domains that hot-unplug should have revoked, corrupting crypto operations the host believes are no longer available to that guest.
A:H - With the stale APCB the guest can PQAP(ZAPQ)-reset or flood the unplugged queues, denying host or sibling-guest crypto services (pkey, secure-key LUKS, openCryptoki) that subsequently reuse the same physical adapter or 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 a host AP QCI change is picked up by ap_scan_bus() and vfio_ap_on_cfg_changed() calls vfio_ap_mdev_hot_unplug_cfg(), which fails to push the cleared shadow APCB into a local KVM guest via kvm_arch_crypto_set_masks(); that is a local sysfs/firmware/KVM path with no network, Bluetooth, or USB exposure.
AC:L - Removing the last adapter, domain, or control domain assigned to a vfio-ap mdev from the host AP configuration empties the shadow APCB so bitmap_andnot() returns false and vfio_ap_mdev_update_guest_apcb() is skipped every time; a single-adapter guest plus sysfs config=0 or HMC unplug is the designed hot-unplug path, with no race or uncontrolled memory layout.
PR:L - The leftover millicode APCB is exercised by the tenant KVM guest or the unprivileged host kvm-group QEMU process that already holds the vfio-ap mdev, not by host root; kvm_arch_crypto_set_masks() is the revocation the guest then bypasses, and user namespaces cannot create that mdev, so privileges stay Low rather than High.
UI:N - Once the last assigned adapter or domain is removed from host QCI, the guest CRYCB still contains the old bits and the guest can issue NQAP/DQAP/PQAP immediately; no separate victim mount, click, or other user action is required.
S:C - The skipped kvm_arch_crypto_set_masks() leaves the guest with millicode-enforced access to AP adapters and domains the host has unplugged, crossing the KVM/vfio-ap passthrough isolation boundary into hardware that may now belong to the host zcrypt stack or another consumer, equivalent to an IOMMU/device isolation bypass.
C:H - Unauthorized APQNs let the guest dequeue AP replies (DQAP) from queues the host believes were unplugged, disclosing cryptographic request/response data and key material on those adapters and domains.
I:H - The guest can enqueue arbitrary AP requests (NQAP) and change hardware queue state on adapters and domains that hot-unplug should have revoked, corrupting crypto operations the host believes are no longer available to that guest.
A:H - With the stale APCB the guest can PQAP(ZAPQ)-reset or flood the unplugged queues, denying host or sibling-guest crypto services (pkey, secure-key LUKS, openCryptoki) that subsequently reuse the same physical adapter or domain.
CVSS 3.1