Look up another CVE · open CVE-2026-80921 in the interactive tracker
CVE-2026-80921
KVM: s390: vsie: zero stale crypto bits
Published 2026-09-09 (39 days ago) by the Linux kernel CNA. Subsystem arch/s390. Debian urgency: not yet assigned.
What to do, per Debian release
Debian's own status for CVE-2026-80921 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 | fixed | 6.1.187-1 | Update the kernel and reboot. Fixed in 6.1.187-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.1.13-1 | Update the kernel and reboot. Fixed in 7.1.13-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 7.1.13-1 | Update the kernel and reboot. Fixed in 7.1.13-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
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.
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.
arch/s390/kvm/vsie.c
- What this is
- KERNEL VIRTUAL MACHINE for s390 (KVM/s390)MAINTAINERS section matched on arch/s390/kvm/ · kvm@vger.kernel.org · Supported
- Kernel module
- kvm
Check it on the machine
grep -w CONFIG_KVM /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.
lsmod | grep -w kvmPrints a line if that module is loaded right now, and nothing if it is not. One that is not loaded can still be loaded later by anything that needs it.
Show whether Debian builds this, per release
Debian builds this, but not on every flavour. At least one release below builds the code on some of its kernel flavours and not on others, so the answer depends on the architecture and flavour installed.
- bookwormBnot built on arm64/rt/arm64, armhf/armmp, armhf/armmp-lpae, armhf/rt/armmp
- trixieBnot built on armel/rpi, armhf/armmp, armhf/armmp-lpae, armhf/rt/armmp
- forky, sidBnot built on armhf/armmp, armhf/armmp-lpae
- bookworm · linux-6.12Bnot built on armhf/armmp, armhf/armmp-lpae, armhf/rt/armmp
- B
- built in on some, a module on others, absent on the rest
- Build switch
- CONFIG_KVM
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-09 (39 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.13%, higher than 2.0% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- not yet assignedsource
- Subsystem
- arch/s390
Upstream fixes
The versions the CNA records as introducing and fixing this, and the commit for each. source
| Introduced | Fixed in | Commit |
|---|---|---|
| 4.20 | 5.10.269 | d110b3297f11 |
| 4.20 | 5.15.220 | 59d51550b5cb |
| 4.20 | 6.1.187 | f6079dca67ec |
| 4.20 | 6.6.156 | 087c19cc60a8 |
| 4.20 | 6.12.108 | 7d23489f5110 |
| 4.20 | 6.18.49 | 935eeba27601 |
| 4.20 | 7.1.13 | d4bcd2df6d0d |
| 4.20 | 7.2.3 | 29b4f7bc2991 |
| 4.20 | 7.3 | 34d5b5b646c9 |
Debian advisories
| Advisory | Date | Shipped to | Debian |
|---|---|---|---|
| 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 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:LAttack complexity, low
- 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:LPrivileges required, low
- 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:NUser interaction, none
- 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:CScope, changed
- 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:HConfidentiality impact, high
- 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:HIntegrity impact, high
- 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:HAvailability impact, high
- 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.