CVE-2022-48763 in Linux
Summary
by MITRE • 06/20/2024
In the Linux kernel, the following vulnerability has been resolved:
KVM: x86: Forcibly leave nested virt when SMM state is toggled
Forcibly leave nested virtualization operation if userspace toggles SMM state via KVM_SET_VCPU_EVENTS or KVM_SYNC_X86_EVENTS. If userspace forces the vCPU out of SMM while it's post-VMXON and then injects an SMI, vmx_enter_smm() will overwrite vmx->nested.smm.vmxon and end up with both vmxon=false and smm.vmxon=false, but all other nVMX state allocated.
Don't attempt to gracefully handle the transition as (a) most transitions are nonsencial, e.g. forcing SMM while L2 is running, (b) there isn't sufficient information to handle all transitions, e.g. SVM wants access to the SMRAM save state, and (c) KVM_SET_VCPU_EVENTS must precede KVM_SET_NESTED_STATE during state restore as the latter disallows putting the vCPU into L2 if SMM is active, and disallows tagging the vCPU as being post-VMXON in SMM if SMM is not active.
Abuse of KVM_SET_VCPU_EVENTS manifests as a WARN and memory leak in nVMX due to failure to free vmcs01's shadow VMCS, but the bug goes far beyond just a memory leak, e.g. toggling SMM on while L2 is active puts the vCPU in an architecturally impossible state.
WARNING: CPU: 0 PID: 3606 at free_loaded_vmcs arch/x86/kvm/vmx/vmx.c:2665 [inline]
WARNING: CPU: 0 PID: 3606 at free_loaded_vmcs+0x158/0x1a0 arch/x86/kvm/vmx/vmx.c:2656 Modules linked in: CPU: 1 PID: 3606 Comm: syz-executor725 Not tainted 5.17.0-rc1-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:free_loaded_vmcs arch/x86/kvm/vmx/vmx.c:2665 [inline]
RIP: 0010:free_loaded_vmcs+0x158/0x1a0 arch/x86/kvm/vmx/vmx.c:2656 Code: 0b eb b3 e8 8f 4d 9f 00 e9 f7 fe ff ff 48 89 df e8 92 4d 9f 00 Call Trace: kvm_arch_vcpu_destroy+0x72/0x2f0 arch/x86/kvm/x86.c:11123 kvm_vcpu_destroy arch/x86/kvm/../../../virt/kvm/kvm_main.c:441 [inline]
kvm_destroy_vcpus+0x11f/0x290 arch/x86/kvm/../../../virt/kvm/kvm_main.c:460 kvm_free_vcpus arch/x86/kvm/x86.c:11564 [inline]
kvm_arch_destroy_vm+0x2e8/0x470 arch/x86/kvm/x86.c:11676 kvm_destroy_vm arch/x86/kvm/../../../virt/kvm/kvm_main.c:1217 [inline]
kvm_put_kvm+0x4fa/0xb00 arch/x86/kvm/../../../virt/kvm/kvm_main.c:1250 kvm_vm_release+0x3f/0x50 arch/x86/kvm/../../../virt/kvm/kvm_main.c:1273 __fput+0x286/0x9f0 fs/file_table.c:311 task_work_run+0xdd/0x1a0 kernel/task_work.c:164 exit_task_work include/linux/task_work.h:32 [inline]
do_exit+0xb29/0x2a30 kernel/exit.c:806 do_group_exit+0xd2/0x2f0 kernel/exit.c:935 get_signal+0x4b0/0x28c0 kernel/signal.c:2862 arch_do_signal_or_restart+0x2a9/0x1c40 arch/x86/kernel/signal.c:868 handle_signal_work kernel/entry/common.c:148 [inline]
exit_to_user_mode_loop kernel/entry/common.c:172 [inline]
exit_to_user_mode_prepare+0x17d/0x290 kernel/entry/common.c:207 __syscall_exit_to_user_mode_work kernel/entry/common.c:289 [inline]
syscall_exit_to_user_mode+0x19/0x60 kernel/entry/common.c:300 do_syscall_64+0x42/0xb0 arch/x86/entry/common.c:86 entry_SYSCALL_64_after_hwframe+0x44/0xae
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 09/17/2025
The vulnerability described in CVE-2022-48763 affects the Linux kernel's KVM implementation on x86 architectures, specifically within the nested virtualization subsystem. This issue stems from improper handling of SMM (System Management Mode) state transitions during virtual machine operations, creating a critical architectural inconsistency that can lead to system instability and potential security implications. The flaw manifests when userspace attempts to manipulate SMM state through KVM_SET_VCPU_EVENTS or KVM_SYNC_X86_EVENTS ioctls while a virtual CPU is operating within nested virtualization context.
The technical root cause lies in the vmx_enter_smm() function within the VMX (Virtual Machine eXtensions) implementation, which fails to properly manage the transition when SMM state is forcibly toggled while the virtual CPU is in a post-VMXON state. When userspace forces the vCPU out of SMM and subsequently injects an SMI, the system ends up in a state where vmx->nested.smm.vmxon is set to false while all other nested VMX state remains allocated, creating an inconsistent architectural state that violates the expected VMX operational model. This condition arises from the lack of proper state validation and cleanup procedures during SMM state transitions, particularly when dealing with the complex interaction between nested virtualization and system management modes.
The operational impact of this vulnerability extends beyond simple memory leaks to include the potential for entering architecturally impossible states that can cause system crashes, data corruption, and denial of service conditions. The warning messages indicate that the system attempts to free VMCS (Virtual Machine Control Structure) resources but fails due to the inconsistent state, leading to memory leaks and potential kernel oops conditions. The specific error trace shows the failure occurring in free_loaded_vmcs function within vmx.c, indicating that the cleanup process cannot properly handle the malformed state. This vulnerability is particularly dangerous because it can be exploited through the KVM_SET_VCPU_EVENTS ioctl, which allows userspace processes to directly manipulate virtual CPU state, potentially enabling privilege escalation or system compromise.
The mitigation strategy for this vulnerability involves forcing an immediate exit from nested virtualization when SMM state transitions are detected, rather than attempting to gracefully handle complex state changes that lack sufficient information for proper management. This approach aligns with the ATT&CK framework's concept of privilege escalation through kernel exploits and addresses the CWE-121 (Stack-based Buffer Overflow) and CWE-122 (Heap-based Buffer Overflow) categories by preventing the exploitation of memory management inconsistencies. The fix ensures that KVM_SET_NESTED_STATE operations cannot proceed when SMM is active, maintaining architectural consistency and preventing the creation of invalid virtual CPU states that could be exploited by malicious actors. This defensive programming approach eliminates the possibility of state corruption while maintaining the fundamental functionality of both nested virtualization and SMM handling within the kernel's virtualization subsystem.