Look up another CVE · open CVE-2026-89920 in the interactive tracker
CVE-2026-89920
KVM: s390: Fix memory corruption by not reinjecting CK machine checks
Published 2026-09-16 (33 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-89920 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 | vulnerable | 6.1.190-1 | No fix published anywhere yet, neither in Debian nor upstream for the series bookworm tracks. Watch the Debian tracker page for this CVE. Advisories for bookworm have historically landed a median of 23 days after publication. |
| Debian 13trixie | vulnerable | 6.12.113-1 | No fix published anywhere yet, neither in Debian nor upstream for the series trixie tracks. Watch the Debian tracker page for this CVE. Advisories for trixie have historically landed a median of 11 days after publication. |
| 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. |
The vulnerability
What the bug is
Channel-subsystem damage machine checks are for the host channel subsystem. The guest channel subsystem is emulated in the userspace VMM. There is no point in forwarding such machine checks into the guest. This also simplifies the machine check reinjection and avoids kfree of a stack variable as reported by sashiko. There might be still machine checks that have the ck bit set with another bit (like instruction damage), mask out the CK bit in s390_backup_mcck_info(), like the CP and ED bits already are.
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/include/asm/nmi.h
arch/s390/kernel/nmi.c
arch/s390/kvm/interrupt.c
- What this is
- S390 ARCHITECTUREMAINTAINERS section matched on arch/s390/ · linux-s390@vger.kernel.org · Supported
Show whether Debian builds this, per release
Debian builds this code. Every release below compiles the affected file into the kernels it ships.
- bookworm, trixie, forky, sidy
- y
- built into the kernel image on every flavour - only a patch removes it
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 Debian linux-config packages
Signals
- Published
- 2026-09-16 (33 days ago)source
- CVSS
- 7.8 high
CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:Hsource recompute it - Attack vector
- local (AV:L)source
- EPSS
- 0.17%, higher than 6.3% 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.13 | 6.18.51 | 6ee52d3af2a1 |
| 4.13 | 7.2.5 | 7077ec953996 |
| 4.13 | 7.3 | 546dde823a36 |
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
- Reached only after a local KVM_RUN puts an s390 vCPU in SIE (kvm_arch_vcpu_ioctl_run -> __vcpu_run -> kvm_s390_enter_exit_sie/sie64a, also vsie). A host CK machine check then hits vcpu_post_run -> kvm_s390_reinject_machine_check. No network or physical path.
- AC:HAttack complexity, high
- The CK bit comes from host lowcore via s390_backup_mcck_info(), not guest or ioctl input. Channel-subsystem damage is a host CSS hardware/firmware condition the attacker cannot induce; guest CSS is emulated in userspace and does not drive the host CSS.
- PR:LPrivileges required, low
- KVM_CREATE_VM and KVM_RUN have no capable() check for ordinary (non-ucontrol) VMs. A kvm-group user who can open /dev/kvm, or a tenant already running in an s390 KVM guest, suffices; host init-namespace root is not required.
- UI:NUser interaction, none
- The attacker issues KVM_RUN on a vCPU they created, or a tenant guest is already in SIE. No separate victim action such as mounting a filesystem, opening a file, or attaching a device is required.
- S:CScope, changed
- kvm_s390_reinject_machine_check runs in the host kernel on the SIE-exit path and kfree()s a stack object, corrupting host allocator state. That crosses the KVM guest-to-hypervisor boundary and can compromise the host and co-located VMs.
- C:HConfidentiality impact, high
- kfree() of the on-stack kvm_s390_interrupt_info treats a kernel stack address as a slab or large-kmalloc object (page_slab/free_large_kmalloc/slab_free), corrupting allocator metadata. That host-kernel memory corruption can be leveraged for disclosure.
- I:HIntegrity impact, high
- The same invalid free corrupts SLUB or page-allocator metadata, which can be turned into an arbitrary host write or control-flow hijack. CNA guidance scores this class of kernel memory corruption as High integrity.
- A:HAvailability impact, high
- kfree of a non-slab stack address hits WARN_ON_ONCE in free_large_kmalloc or slab_free on a bogus object and oopses or panics the host kernel, denying service to the hypervisor and every co-located VM.