LiveActive security incident?Get immediate response
CVE Record

CVE-2025-37957: KVM: SVM: Forcibly leave SMM mode on SHUTDOWN interception

In the Linux kernel, the following vulnerability has been resolved: KVM: SVM: Forcibly leave SMM mode on SHUTDOWN interception 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]

UnknownCVSS not scoredNot KEV-listedUpdated
Discuss exposureBack to CVEs
Glexia's TakeAutomated analysismoderate

Security readout for executives and security teams

Plain-English summary

This is a Linux KVM virtualization bug affecting AMD SVM handling of a virtual CPU shutdown while in System Management Mode. The public record shows a kernel warning and corrective patch behavior, not confirmed real-world compromise. Business risk is mainly to virtualization hosts where untrusted users or workloads can access KVM.

Executive priority

Handle this in normal virtualization-host patch cycles, faster where tenants or untrusted automation can create KVM guests. There is no source-backed evidence of active exploitation, but kernel virtualization bugs deserve disciplined remediation because host stability and isolation are business-critical.

Technical view

KVM SVM could force a vCPU INIT after SHUTDOWN interception while the vCPU remained in SMM, violating KVM’s own reset expectations and triggering a WARN in kvm_vcpu_reset(). The fix forces the vCPU out of SMM before applying the SHUTDOWN-to-INIT behavior. Syzkaller found the issue.

Likely exposure

Exposure is most plausible on Linux hosts running KVM with AMD SVM where local users, containers, or services can create and drive KVM VMs. Ordinary Linux servers without KVM enabled or without untrusted KVM access are less likely to be exposed.

Exploitation context

The source bundle does not show KEV listing, active exploitation, public weaponization, or a CVSS score. The reported trigger was produced by Syzkaller in a controlled test. Impact evidence is incomplete beyond a kernel WARN and corrected KVM state handling.

Researcher notes

The key condition is SHUTDOWN interception on SVM while the vCPU is in SMM, followed by KVM’s INIT-style reset path. The public record frames the observable failure as a WARN, with historical context about nested-mode triple-fault use-after-free avoidance, but does not prove equivalent impact here.

Mitigation direction

  • Apply the Linux stable kernel updates referenced by the CVE record.
  • Prioritize hosts running KVM on AMD SVM hardware.
  • Restrict KVM device access to trusted users and services.
  • Check vendor kernel advisories for backported fixes in distributions.
  • Avoid treating upstream version numbers as distro patch status.

Validation and detection

  • Inventory virtualization hosts with KVM and AMD SVM enabled.
  • Confirm installed kernel packages include the referenced stable fixes or distro backports.
  • Review whether untrusted users can access KVM VM creation paths.
  • Check kernel logs for related KVM WARN events.
  • Track distro advisories until affected package status is explicit.
Prepared
Confidence
medium
Sources
6

Public sources used

Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.

Potential ATT&CK relevance

Conservative CVE-to-ATT&CK context

These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.

ATT&CK lookup starting points

Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.

cve · low confidence lookup

CVE-2025-37957 mapping review

Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.

Open ATT&CK lookup
Vulnerability profileCVE Program record
Severity
Unknown
CVSS
Not scored
Known Exploited
No
Published
Official CVE source material

CNA and ADP enrichment extracted from CVE v5

These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.

0CVSS vectors
3Timeline events
0ADP providers
5Source links

Vulnerability timeline

Timeline events are normalized from CVE metadata, CNA source timelines, ADP timelines, and KEV metadata when present.

  1. CVE reservedCVE Program

    The CVE ID was reserved by the assigning CNA.

  2. CVE publishedCVE Program

    The CVE record was published.

  3. CVE updatedCVE Program

    The CVE record metadata indicates this as the latest update time.

Source materials

Affected products

Products and packages named in the record

VendorProductVersion / packageStatus
LinuxLinuxed129ec9057f89d615ba0c81a4984a90345a1684, ed129ec9057f89d615ba0c81a4984a90345a1684, ed129ec9057f89d615ba0c81a4984a90345a1684, ed129ec9057f89d615ba0c81a4984a90345a1684, 6425c590d0cc6914658a630a40b7f8226aa028c3, d40ef0a511676bd65ca9acb295430c07af59ab85, 5.15.81, 6.0.11unaffected
LinuxLinux6.1, 0, 6.6.92, 6.12.29, 6.14.7, 6.15affected
Weakness

CWE details

No CWE listed

CWE links open Glexia weakness intelligence pages with official CWE context, developer remediation guidance, and related CVE mappings.