CVE-2024-47744

Linux kernel içerisinde aşağıdaki güvenlik açığı giderilmiştir: KVM: Deadlock oluşmasını önlemek için kvm_usage_count'ı korumak amacıyla özel bir mutex kullanın Kilit zincirleri ve SRCU senkronizasyonları nedeniyle x86 üzerinde meydana gelebilecek potansiyel bir deadlock sorununu düzeltmek için kvm_usage_count'ı koruyan özel bir mutex kullanılmıştır. Aşağıdaki lockdep çıktısı analiz edildiğinde; CPU1 #6, CPU0 #1'i bekleyecek, CPU0 #8, CPU2 #3'ü bekleyecek ve CPU2 #7 (okuma/yazma semaforlarının adilliği nedeniyle eğer bir yazıcı varsa) CPU1 #4'ü bekleyecektir. CPU0 CPU1 CPU2 1 lock(&kvm->slots_lock); 2 lock(&vcpu->mutex); 3 lock(&kvm->srcu); 4 lock(cpu_hotplug_lock); 5 lock(kvm_lock); 6 lock(&kvm->slots_lock); 7 lock(cpu_hotplug_lock); 8 sync(&kvm->srcu); Not olarak, KVM x86'da daha fazla potansiyel deadlock olasılığı bulunmaktadır; örneğin, cpu_hotplug_lock kilidinin kvm_lock dışında alınması şeklindeki aynı desen muhtemelen __kvmclock_cpufreq_notifier() fonksiyonunda da mevcuttur: cpuhp_cpufreq_online() | -> cpufreq_online() | -> cpufreq_gov_performance_limits() | -> __cpufreq_driver_target() | -> __target_index() | -> cpufreq_freq_transition_begin() | -> cpufreq_notify_transition() | -> ... __kvmclock_cpufreq_notifier() Ancak, ilgili bağımlılıklar ve zamanlamaların kombinasyonu nedeniyle bu tür deadlock'ların gerçekte tetiklenmesi oldukça nadirdir. Örneğin; cpufreq bildirimi yalnızca sabit TSC'ye sahip olmayan eski CPU'larda kullanılır, VM'ler çalışırken NX hugepage hafifletmesiyle uğraşmak çok nadirdir ve bunu yaparken aynı zamanda bir CPU'yu çevrimiçi/çevrimdışı hale getirmek (cpu_hotplug_lock üzerinde çekişme yaratmak için gereklidir) daha da sıra dışıdır. Genel cpu_hotplug_lock sorununun en sağlam çözümü, muhtemelen vm_list'in RCU ile korunan bir liste haline getirilmesidir; böylece x86'nın cpufreq bildirimi kvm_lock'ı almak zorunda kalmaz. Şimdilik, RCU ile korunan bir listeye geçmek çok daha kapsamlı bir değişiklik olduğu için en belirgin deadlock'un düzeltilmesiyle yetinilmiş, ancak locking.rst dosyasına kvm_lock tutulurken vm_list üzerinden geçildiğinde dikkatli olunması gerektiğine dair bir yorum eklenmiştir. ====================================================== WARNING: possible circular locking dependency detected 6.10.0-smp--c257535a0c9d-pip #330 Tainted: G S O ------------------------------------------------------ tee/35048 is trying to acquire lock: ff6a80eced71e0a8 (&kvm->slots_lock){+.+.}-{3:3}, at: set_nx_huge_pages+0x179/0x1e0 [kvm] but task is already holding lock: ffffffffc07abb08 (kvm_lock){+.+.}-{3:3}, at: set_nx_huge_pages+0x14a/0x1e0 [kvm] which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #3 (kvm_lock){+.+.}-{3:3}: __mutex_lock+0x6a/0xb40 mutex_lock_nested+0x1f/0x30 kvm_dev_ioctl+0x4fb/0xe50 [kvm] __se_sys_ioctl+0x7b/0xd0 __x64_sys_ioctl+0x21/0x30 x64_sys_call+0x15d0/0x2e60 do_syscall_64+0x83/0x160 entry_SYSCALL_64_after_hwframe+0x76/0x7e -> #2 (cpu_hotplug_lock){++++}-{0:0}: cpus_read_lock+0x2e/0xb0 static_key_slow_inc+0x16/0x30 kvm_lapic_set_base+0x6a/0x1c0 [kvm] kvm_set_apic_base+0x8f/0xe0 [kvm] kvm_set_msr_common+0x9ae/0xf80 [kvm] vmx_set_msr+0xa54/0xbe0 [kvm_intel] __kvm_set_msr+0xb6/0x1a0 [kvm] kvm_arch_vcpu_ioctl+0xeca/0x10c0 [kvm] kvm_vcpu_ioctl+0x485/0x5b0 [kvm] __se_sys_ioctl+0x7b/0xd0 __x64_sys_ioctl+0x21/0x30 x64_sys_call+0x15d0/0x2e60 do_syscall_64+0x83/0x160 entry_SYSCALL_64_after_hwframe+0x76/0x7e -> #1 (&kvm->srcu){.+.+}-{0:0}: __synchronize_srcu+0x44/0x1a0 ---truncated---