LiveActive security incident?Get immediate response
CVE Record

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.

UnknownCVSS not scoredNot KEV-listedUpdated
Glexia's TakeAutomated analysisunknown

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.
  • Review kernel logs for repeated KVM AMD nested virtualization WARN events.
  • Confirm patched hosts include the stable KVM nSVM TSC scaling support check.
Prepared
Confidence
medium
Sources
5

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.

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
4Source 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.

Affected products

Products and packages named in the record

VendorProductVersion / packageStatus
LinuxLinux5228eb96a4875f8cf5d61d486e3795ac14df8904, 5228eb96a4875f8cf5d61d486e3795ac14df8904, 5228eb96a4875f8cf5d61d486e3795ac14df8904unaffected
LinuxLinux5.16, 0, 6.1.54, 6.5.4, 6.6affected
Weakness

CWE details

No CWE listed

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