CVE-2023-53208

Linux kernel içerisinde aşağıdaki güvenlik açığı giderilmiştir: KVM: nSVM: L1'in TSC çarpanını L2 durumu yerine L1 durumuna göre yükle İç içe geçmiş (nested) VM-Exit emülasyonu sırasında; eğer L1'in kullandığı oran varsayılan değerden farklıysa değil, L1'in istediği oran mevcut oranla eşleşmiyorsa L1'in TSC çarpanı yüklensin. İşlevsel olarak sonuç aynıdır çünkü L2'nin çarpanı varsayılan ise KVM, L2'yi L1'in çarpanıyla çalıştıracaktır; yani L1'in çarpanının yüklendiğini kontrol etmek, L2'nin varsayılan olmayan bir çarpana sahip olup olmadığını kontrol etmekle eşdeğerdir. Ancak, TSC ölçeklendirmenin L1'e sunulduğu yönündeki varsayım hatalıdır; zira kullanıcı alanı, MSR yazıp ardından özelliği gizlemek için konuk CPUID'sini güncelleyerek (konuk CPUID'sini değiştirmek KVM_RUN öncesinde her zaman mümkündür) isteğe bağlı olarak WARN tetikleyebilir. Örneğin, yeni bir VM+vCPU'da durum geri yüklendikten sonra KVM'nin state_test selftest'ini şu şekilde manipüle etmek: vcpu_set_msr(vcpu, MSR_AMD64_TSC_RATIO, 0); vcpu_clear_cpuid_feature(vcpu, X86_FEATURE_TSCRATEMSR); sürekli olarak şunların üretilmesine neden olur: ------------[ 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 İç içe geçmiş VMRUN yolunun aksine, svm->tsc_scaling_enabled kontrolünü if-ifadesinin içine taşımak yanlıştır çünkü KVM yukarıdaki senaryoda L1'in çarpanının yüklendiğinden emin olmalıdır. Alternatif olarak, WARN_ON() basitçe silinebilirdi ancak bu, KVM'nin davranışını daha belirsiz hale getirirdi; örneğin sadece tsc_ratio_msr kontrol edilirken MSR_AMD64_TSC_RATIO yazmanın neden güvenli olduğu hemen anlaşılmazdı.