CVE-2023-53663: KVM: nSVM: Check instead of asserting on nested TSC scaling support
In the Linux kernel, the following vulnerability has been resolved:
KVM: nSVM: Check instead of asserting on nested TSC scaling support
Check for nested TSC scaling support on nested SVM VMRUN instead of
asserting that TSC scaling is exposed to L1 if L1's MSR_AMD64_TSC_RATIO
has diverged from KVM's default. Userspace can trigger the WARN at will
by writing the MSR and then updating guest CPUID to hide the feature
(modifying guest CPUID is allowed anytime before KVM_RUN). E.g. hacking
KVM's state_test selftest to do
vcpu_set_msr(vcpu, MSR_AMD64_TSC_RATIO, 0);
vcpu_clear_cpuid_feature(vcpu, X86_FEATURE_TSCRATEMSR);
after restoring state in a new VM+vCPU yields an endless supply of:
------------[ cut here ]------------
WARNING: CPU: 164 PID: 62565 at arch/x86/kvm/svm/nested.c:699
nested_vmcb02_prepare_control+0x3d6/0x3f0 [kvm_amd]
Call Trace:
<TASK>
enter_svm_guest_mode+0x114/0x560 [kvm_amd]
nested_svm_vmrun+0x260/0x330 [kvm_amd]
vmrun_interception+0x29/0x30 [kvm_amd]
svm_invoke_exit_handler+0x35/0x100 [kvm_amd]
svm_handle_exit+0xe7/0x180 [kvm_amd]
kvm_arch_vcpu_ioctl_run+0x1eab/0x2570 [kvm]
kvm_vcpu_ioctl+0x4c9/0x5b0 [kvm]
__se_sys_ioctl+0x7a/0xc0
__x64_sys_ioctl+0x21/0x30
do_syscall_64+0x41/0x90
entry_SYSCALL_64_after_hwframe+0x63/0xcd
RIP: 0033:0x45ca1b
Note, the nested #VMEXIT path has the same flaw, but needs a different
fix and will be handled separately.
Security readout for executives and security teams
Plain-English summary
This is a Linux KVM issue in AMD nested virtualization. A user with access to create or run KVM guests can trigger repeated kernel warnings by presenting inconsistent nested TSC scaling state. Sources do not show remote exploitation, public weaponization, CVSS, or KEV listing.
Executive priority
Treat as a virtualization host hygiene issue. Patch affected KVM hosts during the next maintenance window, sooner for shared or tenant-controlled virtualization environments. Current evidence does not justify emergency response without affected exposure.
Technical view
KVM nSVM previously asserted that nested TSC scaling was exposed to L1 when L1 TSC ratio state differed from the default. Userspace could change guest CPU state before KVM_RUN and trigger a WARN in nested VMRUN handling. The fix changes assertion behavior to an explicit support check.
Likely exposure
Exposure is most likely on Linux hosts using KVM with AMD SVM nested virtualization, especially where untrusted users or tenants can control VM CPU state. The source bundle does not define exact affected version ranges beyond listed Linux versions and stable commit references.
Exploitation context
The provided sources say userspace can trigger the warning at will before KVM_RUN. There is no KEV entry and no cited evidence of active exploitation. The stated impact is kernel WARN behavior; broader availability or privilege impact is not established in the bundle.
Researcher notes
The bundle notes a related nested #VMEXIT flaw needing a separate fix, so do not assume this patch covers all similar paths. Version and impact evidence is incomplete; validate against downstream kernel advisories before making fleet-wide severity claims.
Mitigation direction
Apply vendor Linux kernel updates containing the referenced stable fixes.
Prioritize KVM hosts that enable AMD nested virtualization for untrusted users.
Check distribution advisories for exact package versions and backports.
Restrict KVM access to trusted administrators where patching is delayed.
Validation and detection
Inventory Linux KVM hosts using AMD SVM or nested virtualization.
Check kernel package changelogs for CVE-2023-53663 or referenced commit IDs.
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-2023-53663 mapping review
Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.
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
4Source links
Vulnerability timeline
Timeline events are normalized from CVE metadata, CNA source timelines, ADP timelines, and KEV metadata when present.
CVE reservedCVE Program
The CVE ID was reserved by the assigning CNA.
CVE publishedCVE Program
The CVE record was published.
Oct 7, 2025, 15:21 UTC (UTC+00:00)
CVE updatedCVE Program
The CVE record metadata indicates this as the latest update time.