ghsa-5vj7-r55g-9xv7
Vulnerability from github
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: 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]
{
"affected": [],
"aliases": [
"CVE-2025-37957"
],
"database_specific": {
"cwe_ids": [],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-05-20T16:15:33Z",
"severity": null
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nKVM: SVM: Forcibly leave SMM mode on SHUTDOWN interception\n\nPreviously, commit ed129ec9057f (\"KVM: x86: forcibly leave nested mode\non vCPU reset\") addressed an issue where a triple fault occurring in\nnested mode could lead to use-after-free scenarios. However, the commit\ndid not handle the analogous situation for System Management Mode (SMM).\n\nThis omission results in triggering a WARN when KVM forces a vCPU INIT\nafter SHUTDOWN interception while the vCPU is in SMM. This situation was\nreprodused using Syzkaller by:\n\n 1) Creating a KVM VM and vCPU\n 2) Sending a KVM_SMI ioctl to explicitly enter SMM\n 3) Executing invalid instructions causing consecutive exceptions and\n eventually a triple fault\n\nThe issue manifests as follows:\n\n WARNING: CPU: 0 PID: 25506 at arch/x86/kvm/x86.c:12112\n kvm_vcpu_reset+0x1d2/0x1530 arch/x86/kvm/x86.c:12112\n Modules linked in:\n CPU: 0 PID: 25506 Comm: syz-executor.0 Not tainted\n 6.1.130-syzkaller-00157-g164fe5dde9b6 #0\n Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),\n BIOS 1.12.0-1 04/01/2014\n RIP: 0010:kvm_vcpu_reset+0x1d2/0x1530 arch/x86/kvm/x86.c:12112\n Call Trace:\n \u003cTASK\u003e\n shutdown_interception+0x66/0xb0 arch/x86/kvm/svm/svm.c:2136\n svm_invoke_exit_handler+0x110/0x530 arch/x86/kvm/svm/svm.c:3395\n svm_handle_exit+0x424/0x920 arch/x86/kvm/svm/svm.c:3457\n vcpu_enter_guest arch/x86/kvm/x86.c:10959 [inline]\n vcpu_run+0x2c43/0x5a90 arch/x86/kvm/x86.c:11062\n kvm_arch_vcpu_ioctl_run+0x50f/0x1cf0 arch/x86/kvm/x86.c:11283\n kvm_vcpu_ioctl+0x570/0xf00 arch/x86/kvm/../../../virt/kvm/kvm_main.c:4122\n vfs_ioctl fs/ioctl.c:51 [inline]\n __do_sys_ioctl fs/ioctl.c:870 [inline]\n __se_sys_ioctl fs/ioctl.c:856 [inline]\n __x64_sys_ioctl+0x19a/0x210 fs/ioctl.c:856\n do_syscall_x64 arch/x86/entry/common.c:51 [inline]\n do_syscall_64+0x35/0x80 arch/x86/entry/common.c:81\n entry_SYSCALL_64_after_hwframe+0x6e/0xd8\n\nArchitecturally, INIT is blocked when the CPU is in SMM, hence KVM\u0027s WARN()\nin kvm_vcpu_reset() to guard against KVM bugs, e.g. to detect improper\nemulation of INIT. SHUTDOWN on SVM is a weird edge case where KVM needs to\ndo _something_ sane with the VMCB, since it\u0027s technically undefined, and\nINIT is the least awful choice given KVM\u0027s ABI.\n\nSo, double down on stuffing INIT on SHUTDOWN, and force the vCPU out of\nSMM to avoid any weirdness (and the WARN).\n\nFound by Linux Verification Center (linuxtesting.org) with Syzkaller.\n\n[sean: massage changelog, make it clear this isn\u0027t architectural behavior]",
"id": "GHSA-5vj7-r55g-9xv7",
"modified": "2025-05-22T15:34:48Z",
"published": "2025-05-20T18:30:56Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37957"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a2620f8932fa9fdabc3d78ed6efb004ca409019f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d362b21fefcef7eda8f1cd78a5925735d2b3287c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e9b28bc65fd3a56755ba503258024608292b4ab1"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ec24e62a1dd3540ee696314422040180040c1e4a"
}
],
"schema_version": "1.4.0",
"severity": []
}
Sightings
| Author | Source | Type | Date |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or seen somewhere by the user.
- Confirmed: The vulnerability is confirmed from an analyst perspective.
- Exploited: This vulnerability was exploited and seen by the user reporting the sighting.
- Patched: This vulnerability was successfully patched by the user reporting the sighting.
- Not exploited: This vulnerability was not exploited or seen by the user reporting the sighting.
- Not confirmed: The user expresses doubt about the veracity of the vulnerability.
- Not patched: This vulnerability was not successfully patched by the user reporting the sighting.