CVE-2023-53208

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: nSVM: Load L1&amp;#39;s TSC multiplier based on L1 state, not L2 state<br /> <br /> When emulating nested VM-Exit, load L1&amp;#39;s TSC multiplier if L1&amp;#39;s desired<br /> ratio doesn&amp;#39;t match the current ratio, not if the ratio L1 is using for<br /> L2 diverges from the default. Functionally, the end result is the same<br /> as KVM will run L2 with L1&amp;#39;s multiplier if L2&amp;#39;s multiplier is the default,<br /> i.e. checking that L1&amp;#39;s multiplier is loaded is equivalent to checking if<br /> L2 has a non-default multiplier.<br /> <br /> However, the assertion that TSC scaling is exposed to L1 is flawed, as<br /> userspace can trigger the WARN at will by writing the MSR and then<br /> updating guest CPUID to hide the feature (modifying guest CPUID is<br /> allowed anytime before KVM_RUN). E.g. hacking KVM&amp;#39;s state_test<br /> selftest to do<br /> <br /> vcpu_set_msr(vcpu, MSR_AMD64_TSC_RATIO, 0);<br /> vcpu_clear_cpuid_feature(vcpu, X86_FEATURE_TSCRATEMSR);<br /> <br /> after restoring state in a new VM+vCPU yields an endless supply of:<br /> <br /> ------------[ cut here ]------------<br /> WARNING: CPU: 10 PID: 206939 at arch/x86/kvm/svm/nested.c:1105<br /> nested_svm_vmexit+0x6af/0x720 [kvm_amd]<br /> Call Trace:<br /> nested_svm_exit_handled+0x102/0x1f0 [kvm_amd]<br /> svm_handle_exit+0xb9/0x180 [kvm_amd]<br /> kvm_arch_vcpu_ioctl_run+0x1eab/0x2570 [kvm]<br /> kvm_vcpu_ioctl+0x4c9/0x5b0 [kvm]<br /> ? trace_hardirqs_off+0x4d/0xa0<br /> __se_sys_ioctl+0x7a/0xc0<br /> __x64_sys_ioctl+0x21/0x30<br /> do_syscall_64+0x41/0x90<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> <br /> Unlike the nested VMRUN path, hoisting the svm-&gt;tsc_scaling_enabled check<br /> into the if-statement is wrong as KVM needs to ensure L1&amp;#39;s multiplier is<br /> loaded in the above scenario. Alternatively, the WARN_ON() could simply<br /> be deleted, but that would make KVM&amp;#39;s behavior even more subtle, e.g. it&amp;#39;s<br /> not immediately obvious why it&amp;#39;s safe to write MSR_AMD64_TSC_RATIO when<br /> checking only tsc_ratio_msr.