Look up another CVE · open CVE-2025-37957 in the interactive tracker
CVE-2025-37957
KVM: SVM: Forcibly leave SMM mode on SHUTDOWN interception
Published 2025-05-20 (17 months ago) by the Linux kernel CNA. Subsystem arch/x86. Debian urgency: not yet assigned.
What to do, per Debian release
Debian's own status for CVE-2025-37957 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 | fixed | 6.12.29-1 | Update the kernel and reboot. Fixed in 6.12.29-1. A running kernel keeps the old code until the machine restarts. |
| Debian 14forky | fixed | 6.12.29-1 | Update the kernel and reboot. Fixed in 6.12.29-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 6.12.29-1 | Update the kernel and reboot. Fixed in 6.12.29-1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
Previously, commit ed129ec9057f ("KVM: x86: forcibly leave nested mode on vCPU reset") addressed an issue where a triple fault occurring in nested mode could lead to use-after-free scenarios. However, the commit did not handle the analogous situation for System Management Mode (SMM). This omission results in triggering a WARN when KVM forces a vCPU INIT after SHUTDOWN interception while the vCPU is in SMM. This situation was reprodused using Syzkaller by: 1) Creating a KVM VM and vCPU 2) Sending a KVM_SMI ioctl to explicitly enter SMM 3) Executing invalid instructions causing consecutive exceptions and eventually a triple fault The issue manifests as follows: WARNING: CPU: 0 PID: 25506 at arch/x86/kvm/x86.c:12112 kvm_vcpu_reset+0x1d2/0x1530 arch/x86/kvm/x86.c:12112 Modules linked in: CPU: 0 PID: 25506 Comm: syz-executor.0 Not tainted 6.1.130-syzkaller-00157-g164fe5dde9b6 #0 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014 RIP: 0010:kvm_vcpu_reset+0x1d2/0x1530 arch/x86/kvm/x86.c:12112 Call Trace: <TASK> shutdown_interception+0x66/0xb0 arch/x86/kvm/svm/svm.c:2136 svm_invoke_exit_handler+0x110/0x530 arch/x86/kvm/svm/svm.c:3395 svm_handle_exit+0x424/0x920 arch/x86/kvm/svm/svm.c:3457 vcpu_enter_guest arch/x86/kvm/x86.c:10959 [inline] vcpu_run+0x2c43/0x5a90 arch/x86/kvm/x86.c:11062 kvm_arch_vcpu_ioctl_run+0x50f/0x1cf0 arch/x86/kvm/x86.c:11283 kvm_vcpu_ioctl+0x570/0xf00 arch/x86/kvm/../../../virt/kvm/kvm_main.c:4122 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:870 [inline] __se_sys_ioctl fs/ioctl.c:856 [inline] __x64_sys_ioctl+0x19a/0x210 fs/ioctl.c:856 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x35/0x80 arch/x86/entry/common.c:81 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 Architecturally, INIT is blocked when the CPU is in SMM, hence KVM's WARN() in kvm_vcpu_reset() to guard against KVM bugs, e.g. to detect improper emulation of INIT. SHUTDOWN on SVM is a weird edge case where KVM needs to do _something_ sane with the VMCB, since it's technically undefined, and INIT is the least awful choice given KVM's ABI. So, double down on stuffing INIT on SHUTDOWN, and force the vCPU out of SMM to avoid any weirdness (and the WARN). Found by Linux Verification Center (linuxtesting.org) with Syzkaller. [sean: massage changelog, make it clear this isn't architectural behavior]
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/x86/kvm/smm.c
arch/x86/kvm/svm/svm.c
- What this is
- KERNEL VIRTUAL MACHINE FOR X86 (KVM/x86)MAINTAINERS section matched on arch/x86/kvm/ · kvm@vger.kernel.org · Supported
- Kernel module
- kvm
Check it on the machine
grep -wE 'CONFIG_KVM|CONFIG_KVM_SMM|CONFIG_KVM_X86' /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. The build rule could not be established for 1 release, so nothing is claimed about those.
- bookworm?
- trixieMnot built on arm64/arm64, arm64/arm64-16k, arm64/cloud-arm64, arm64/rt/arm64, armel/rpi, armhf/armmp, armhf/armmp-lpae, armhf/rt/armmp, ppc64el/powerpc64le, ppc64el/powerpc64le-64k, riscv64/riscv64, s390x/s390x
- forky, sidMnot built on arm64/arm64, arm64/arm64-16k, arm64/cloud-arm64, arm64/rt-arm64, armhf/armmp, armhf/armmp-lpae, loong64/loong64, ppc64el/powerpc64le, ppc64el/powerpc64le-64k, riscv64/riscv64, s390x/s390x
- ?
- not established - no Makefile entry for the affected file
- M
- a module where it is built at all; some flavours do not build it
Where a release above reads "not established", no build rule for the affected file was found in that release's kernel tree. That is a gap in this lookup, not a finding that the code is absent.
- Build switches
- CONFIG_KVM, CONFIG_KVM_SMM, CONFIG_KVM_X86
- 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
- 2025-05-20 (17 months 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.19%, higher than 8.3% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- not yet assignedsource
- Subsystem
- arch/x86
Upstream fixes
The versions the CNA records as introducing and fixing this, and the commit for each. source
| Introduced | Fixed in | Commit |
|---|---|---|
| 6.1 | 6.6.92 | ec24e62a1dd3 |
| 6.1 | 6.12.29 | d362b21fefce |
| 6.1 | 6.14.7 | e9b28bc65fd3 |
| 6.1 | 6.15 | a2620f8932fa |
| 5.15.81 | 0 | 0 |
| 6.0.11 | 0 | 0 |
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 vulnerability is reached through the local KVM device interface (`KVM_SMI` + `KVM_RUN` ioctls on /dev/kvm) or by code executing inside a guest VM on the local host; no network protocol handling is involved.
- AC:LAttack complexity, low
- The trigger is fully deterministic and attacker-controlled — enter SMM, then execute instructions that cause consecutive faults until a triple fault, which unconditionally hits the SHUTDOWN intercept; syzkaller reproduced it reliably with no race or memory-layout dependency.
- PR:LPrivileges required, low
- The attacker needs only access to /dev/kvm (routinely granted to the unprivileged `kvm` group and to sandboxed VMM processes such as QEMU), or ring-0 in a guest to write the LAPIC ICR with SMI delivery mode; no root or CAP_SYS_ADMIN in the init namespace is required.
- UI:NUser interaction, none
- The attacker performs the entire sequence itself via ioctls or guest instruction execution; no action by any other user or administrator is needed.
- S:CScope, changed
- The attacker is confined to a VM/VMM sandbox, but the corrupted state lives in the host kernel's KVM MMU, so the impact escapes that confinement to the host and to other guests on the same host; the stale `smm=1` root additionally breaches the SMM/SMRAM boundary the VMM enforces.
- C:HConfidentiality impact, high
- The vCPU resumes with an MMU root tagged for the SMM address space while KVM believes it is not in SMM, granting the guest read access to SMRAM and leaving address-space-mismatched SPTEs that slot-scoped zaps never invalidate, yielding dangling read mappings into freed host pages.
- I:HIntegrity impact, high
- The same address-space-confused SPTEs are writable, so the guest can write to SMRAM (defeating firmware/secure-boot protections) and to host pages that have been freed or migrated away, providing a host memory write primitive.
- A:HAvailability impact, high
- The WARN_ON_ONCE in kvm_vcpu_reset() is hit on demand, which is an immediate host kernel panic on the widely deployed `panic_on_warn=1` hardened configuration, and the resulting inconsistent vCPU/MMU state can crash the host independently.