CVE-2023-53208
published 2025-09-15CVE-2023-53208: In the Linux kernel, the following vulnerability has been resolved: KVM: nSVM: Load L1's TSC multiplier based on L1 state, not L2 state When emulating nested…
PriorityP421medium5.5CVSS 3.1
AVLACLPRLUINSUCNINAH
EPSS
0.14%
4.1th percentile
In the Linux kernel, the following vulnerability has been resolved:
KVM: nSVM: Load L1's TSC multiplier based on L1 state, not L2 state
When emulating nested VM-Exit, load L1's TSC multiplier if L1's desired
ratio doesn't match the current ratio, not if the ratio L1 is using for
L2 diverges from the default. Functionally, the end result is the same
as KVM will run L2 with L1's multiplier if L2's multiplier is the default,
i.e. checking that L1's multiplier is loaded is equivalent to checking if
L2 has a non-default multiplier.
However, the assertion that TSC scaling is exposed to L1 is flawed, as
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: 10 PID: 206939 at arch/x86/kvm/svm/nested.c:1105
nested_svm_vmexit+0x6af/0x720 [kvm_amd]
Call Trace:
nested_svm_exit_handled+0x102/0x1f0 [kvm_amd]
svm_handle_exit+0xb9/0x180 [kvm_amd]
kvm_arch_vcpu_ioctl_run+0x1eab/0x2570 [kvm]
kvm_vcpu_ioctl+0x4c9/0x5b0 [kvm]
? trace_hardirqs_off+0x4d/0xa0
__se_sys_ioctl+0x7a/0xc0
__x64_sys_ioctl+0x21/0x30
do_syscall_64+0x41/0x90
entry_SYSCALL_64_after_hwframe+0x63/0xcd
Unlike the nested VMRUN path, hoisting the svm->tsc_scaling_enabled check
into the if-statement is wrong as KVM needs to ensure L1's multiplier is
loaded in the above scenario. Alternatively, the WARN_ON() could simply
be deleted, but that would make KVM's behavior even more subtle, e.g. it's
not immediately obvious why it's safe to write MSR_AMD64_TSC_RATIO when
checking only tsc_ratio_msr.
Affected
10 ranges
| Vendor | Product | Version range | Fixed in |
|---|---|---|---|
| debian | linux | < linux 6.1.55-1 (bookworm) | linux 6.1.55-1 (bookworm) |
| linux | linux | — | — |
| linux | linux | >= 5228eb96a4875f8cf5d61d486e3795ac14df8904 < 5b2b0535fa7adee7e295fed0a3095082131a8d05 | 5b2b0535fa7adee7e295fed0a3095082131a8d05 |
| linux | linux | >= 5228eb96a4875f8cf5d61d486e3795ac14df8904 < e91c07f6cf7060d2acb3aeee31a6baebe3773d3f | e91c07f6cf7060d2acb3aeee31a6baebe3773d3f |
| linux | linux | >= 5228eb96a4875f8cf5d61d486e3795ac14df8904 < 0c94e2468491cbf0754f49a5136ab51294a96b69 | 0c94e2468491cbf0754f49a5136ab51294a96b69 |
| linux | linux_kernel | >= 0 < 6.1.55-1 | 6.1.55-1 |
| linux | linux_kernel | >= 0 < 6.5.6-1 | 6.5.6-1 |
| linux | linux_kernel | >= 0 < 6.5.6-1 | 6.5.6-1 |
| linux | linux_kernel | >= 5.16 < 6.1.54 | 6.1.54 |
| linux | linux_kernel | >= 6.2 < 6.5.4 | 6.5.4 |
CVSS provenance
nvdv3.15.5MEDIUMCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
osv5.5MEDIUM
vendor_debian5.5MEDIUM
vendor_redhat5.5MEDIUM
Stop checking back — get the weekly exploitation signal.
Every Monday: what got weaponized or added to CISA KEV in the last seven days — each CVE cross-linked to its PoC, Nuclei template, and detection rule. Free, one email a week, unsubscribe in one click.
OSV
CVE-2023-53208: In the Linux kernel, the following vulnerability has been resolved: KVM: nSVM: Load L1's TSC multiplier based on L1 state, not L2 state When emulating
osv·2025-09-15·CVSS 5.5
CVE-2023-53208 [MEDIUM] CVE-2023-53208: In the Linux kernel, the following vulnerability has been resolved: KVM: nSVM: Load L1's TSC multiplier based on L1 state, not L2 state When emulating
In the Linux kernel, the following vulnerability has been resolved: KVM: nSVM: Load L1's TSC multiplier based on L1 state, not L2 state When emulating nested VM-Exit, load L1's TSC multiplier if L1's desired ratio doesn't match the current ratio, not if the ratio L1 is using for L2 diverges from the default. Functionally, the end result is the same as KVM will run L2 with L1's multiplier if L2's multiplier is the default, i.e. checking that L1's multiplier is loaded is equivalent to checking if L2 has a non-default multiplier. However, the assertion that TSC scaling is exposed to L1 is flawed, as 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
GHSA
GHSA-2h47-q9f6-8gx7: In the Linux kernel, the following vulnerability has been resolved:
KVM: nSVM: Load L1's TSC multiplier based on L1 state, not L2 state
When emulati
ghsa_unreviewed·2025-09-15
CVE-2023-53208 [MEDIUM] GHSA-2h47-q9f6-8gx7: In the Linux kernel, the following vulnerability has been resolved:
KVM: nSVM: Load L1's TSC multiplier based on L1 state, not L2 state
When emulati
In the Linux kernel, the following vulnerability has been resolved:
KVM: nSVM: Load L1's TSC multiplier based on L1 state, not L2 state
When emulating nested VM-Exit, load L1's TSC multiplier if L1's desired
ratio doesn't match the current ratio, not if the ratio L1 is using for
L2 diverges from the default. Functionally, the end result is the same
as KVM will run L2 with L1's multiplier if L2's multiplier is the default,
i.e. checking that L1's multiplier is loaded is equivalent to checking if
L2 has a non-default multiplier.
However, the assertion that TSC scaling is exposed to L1 is flawed, as
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_t
Red Hat
kernel: Linux kernel KVM: Denial of Service in nested SVM due to TSC multiplier manipulation
vendor_redhat·2025-09-15·CVSS 5.5
CVE-2023-53208 [MEDIUM] CWE-670 kernel: Linux kernel KVM: Denial of Service in nested SVM due to TSC multiplier manipulation
kernel: Linux kernel KVM: Denial of Service in nested SVM due to TSC multiplier manipulation
In the Linux kernel, the following vulnerability has been resolved:
KVM: nSVM: Load L1's TSC multiplier based on L1 state, not L2 state
When emulating nested VM-Exit, load L1's TSC multiplier if L1's desired
ratio doesn't match the current ratio, not if the ratio L1 is using for
L2 diverges from the default. Functionally, the end result is the same
as KVM will run L2 with L1's multiplier if L2's multiplier is the default,
i.e. checking that L1's multiplier is loaded is equivalent to checking if
L2 has a non-default multiplier.
However, the assertion that TSC scaling is exposed to L1 is flawed, as
userspace can trigger the WARN at will by writing the MSR and then
updating guest CPUID to hide the fe
Debian
CVE-2023-53208: linux - In the Linux kernel, the following vulnerability has been resolved: KVM: nSVM: ...
vendor_debian·2023·CVSS 5.5
CVE-2023-53208 [MEDIUM] CVE-2023-53208: linux - In the Linux kernel, the following vulnerability has been resolved: KVM: nSVM: ...
In the Linux kernel, the following vulnerability has been resolved: KVM: nSVM: Load L1's TSC multiplier based on L1 state, not L2 state When emulating nested VM-Exit, load L1's TSC multiplier if L1's desired ratio doesn't match the current ratio, not if the ratio L1 is using for L2 diverges from the default. Functionally, the end result is the same as KVM will run L2 with L1's multiplier if L2's multiplier is the default, i.e. checking that L1's multiplier is loaded is equivalent to checking if L2 has a non-default multiplier. However, the assertion that TSC scaling is exposed to L1 is flawed, as 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
No detection rules found.
No public exploits indexed.
2025-09-15
Published