Look up another CVE · open CVE-2026-89957 in the interactive tracker
CVE-2026-89957
s390/vfio-ap: Fix hot-unplug skipped when last AP adapter or domain removed
Published 2026-09-16 (33 days ago) by the Linux kernel CNA. Subsystem drivers/s390. Debian urgency: not yet assigned.
Debian does not build this code. The per-release build detail is under "Where it lives" below.
What to do, per Debian release
Debian's own status for CVE-2026-89957 in every release this site tracks, and what each one means in practice. Every status below is the one the Debian Security Team publishes for this CVE. source
| Release | Status | Version | What this means |
|---|---|---|---|
| Debian 12bookworm | fixedDLA-4841-1 · 2026-10-17 · text | 6.1.190-1 | Update the kernel and reboot. DLA-4841-1 shipped the fix on 2026-10-17, in 6.1.190-1. A running kernel keeps the old code until the machine restarts. |
| Debian 13trixie | fixedDSA-6528-1 · 2026-09-29 · text | 6.12.111-1 | Update the kernel and reboot. DSA-6528-1 shipped the fix on 2026-09-29, in 6.12.111-1. A running kernel keeps the old code until the machine restarts. |
| Debian 14forky | fixed | 7.2.6-1 | Update the kernel and reboot. Fixed in 7.2.6-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 7.2.6-1 | Update the kernel and reboot. Fixed in 7.2.6-1. A running kernel keeps the old code until the machine restarts. |
| Debian 12bookworm · linux-6.12 | fixedDLA-4817-1 · 2026-10-04 · text | 6.12.111-1~deb12u1 | Update the kernel and reboot. DLA-4817-1 shipped the fix on 2026-10-04, in 6.12.111-1~deb12u1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
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.
Where it lives
The fix touches these files. If the subsystem is one you do not use, the practical exposure is lower, though the package is still the vulnerable one.
drivers/s390/crypto/vfio_ap_ops.c
- What this is
- S390 VFIO AP DRIVERMAINTAINERS section matched on drivers/s390/crypto/vfio_ap* · linux-s390@vger.kernel.org · Supported
Check it on the machine
grep -wE 'CONFIG_S390|CONFIG_VFIO_AP' /boot/config-$(uname -r)Reads the booted kernel's own configuration, on the machine and nowhere else. =y is built in, =m is a module, and an is not set line means the code is not there.
Show whether Debian builds this, per release
Debian does not build this code. In 5 releases below, every kernel flavour Debian publishes has the switch off, so the vulnerable file is compiled into no kernel binary Debian ships.
- bookworm, trixie, forky, sid, bookworm · linux-6.12n
- n
- not enabled on any flavour - this release does not build the code
- Build switches
- CONFIG_S390, CONFIG_VFIO_AP
- Reads as
- all on means the file is compiled; any one off means it is not.
From the configuration Debian publishes for every kernel flavour it builds. It covers only the architectures Debian ships a linux-config package for, and nothing about a kernel you built yourself. Debian's own status above stays authoritative about the source package.MAINTAINERS kbuild Makefiles Debian linux-config packages
Signals
- Published
- 2026-09-16 (33 days ago)source
- CVSS
- 8.8 high
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:Hsource recompute it - Attack vector
- local (AV:L)source
- EPSS
- 0.16%, higher than 5.3% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- not yet assignedsource
- Subsystem
- drivers/s390
Upstream fixes
The versions the CNA records as introducing and fixing this, and the commit for each. source
| Introduced | Fixed in | Commit |
|---|---|---|
| 6.0 | 6.1.188 | f58e824de857 |
| 6.0 | 6.6.157 | 3a9b049bbdc4 |
| 6.0 | 6.12.110 | 753aa3bb1273 |
| 6.0 | 6.18.51 | c45753c32d45 |
| 6.0 | 7.2.5 | 04b35dd88c10 |
| 6.0 | 7.3 | 917f509bfb88 |
Debian advisories
| Advisory | Date | Shipped to | Debian |
|---|---|---|---|
| DLA-4841-1 | 2026-10-17 | bookworm 6.1.190-1 | tracker |
| DLA-4817-1 | 2026-10-04 | bookworm 6.12.111-1~deb12u1 | tracker |
| DSA-6528-1 | 2026-09-29 | trixie 6.12.111-1 | tracker |
Why the CNA scored it this way
Quoted from the kernel CNA's own scoring file, word for word. A highlighted metric carries the most severe value CVSS v3.1 defines for it, which is what pushes the score up. source
- AV:LAttack vector, local
- 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:LAttack complexity, low
- 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:LPrivileges required, low
- 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:NUser interaction, none
- 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:CScope, changed
- 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:HConfidentiality impact, high
- 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:HIntegrity impact, high
- 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:HAvailability impact, high
- 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.