CVE-2023-53663
BaseFortify
Publication date: 2025-10-07
Last updated on: 2026-02-26
Assigner: kernel.org
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| linux | kvm_amd | * |
| linux | kvm | * |
| linux | linux_kernel | From 5.15.160 (inc) to 5.16 (inc) |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-UNKNOWN |
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?
This vulnerability in the Linux kernel's KVM (Kernel-based Virtual Machine) relates to nested SVM (Secure Virtual Machine) TSC (Time Stamp Counter) scaling support. Instead of properly checking for nested TSC scaling support during nested VMRUN operations, the kernel asserts that TSC scaling is exposed to the first-level guest (L1) if L1's MSR_AMD64_TSC_RATIO register has diverged from KVM's default. This assertion can be triggered by userspace by writing to the MSR and then modifying the guest CPUID to hide the feature, causing an endless warning loop and potential instability in nested virtualization environments.
How can this vulnerability impact me? :
The vulnerability can cause instability or crashes in nested virtualization environments using KVM on Linux. Specifically, userspace can trigger repeated warnings and potentially disrupt the operation of virtual machines by manipulating the MSR_AMD64_TSC_RATIO and guest CPUID features. This could lead to denial of service or degraded performance in systems relying on nested virtualization.
How can this vulnerability be detected on my network or system? Can you suggest some commands?
This vulnerability can be detected by monitoring the system logs for repeated WARNINGS related to nested TSC scaling support in KVM's nested SVM. Specifically, look for messages similar to: 'WARNING: CPU: ... nested_vmcb02_prepare_control+0x3d6/0x3f0 [kvm_amd]'. You can use commands like 'dmesg | grep -i kvm' or 'journalctl -k | grep -i kvm' to find such warnings. Additionally, monitoring for repeated WARN messages related to nested SVM in kernel logs can indicate the presence of this issue.
What immediate steps should I take to mitigate this vulnerability?
Immediate mitigation involves updating the Linux kernel to a version where this vulnerability is fixed. The fix involves checking for nested TSC scaling support on nested SVM VMRUN instead of asserting, preventing the WARN from being triggered. Until the kernel is updated, avoid manipulating the MSR_AMD64_TSC_RATIO and guest CPUID features in ways that trigger this condition. If possible, disable nested virtualization features that use nested SVM to reduce exposure.