CVE-2024-47744 in Linux
Sumário
de VulDB • 31/05/2026
No kernel do Linux, a seguinte vulnerabilidade foi resolvida:
KVM: Utilizar mutex dedicado para proteger kvm_usage_count e evitar deadlock
Utilizar um mutex dedicado para proteger kvm_usage_count corrige um possível deadlock no x86 devido a uma cadeia de bloqueios e sincronizações SRCU. Traduzindo o aviso do lockdep abaixo, a CPU1 #6 aguardará pela CPU0 #1, a CPU0 #8 aguardará pela CPU2 #3 e a CPU2 #7 aguardará pela CPU1 #4 (caso haja um escritor, devido à justiça dos semáforos de leitura/escrita).
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);
Note-se que provavelmente existem mais deadlocks potenciais no KVM x86, por exemplo, o mesmo padrão de adquirir cpu_hotplug_lock fora de kvm_lock provavelmente existe com __kvmclock_cpufreq_notifier():
cpuhp_cpufreq_online() | -> cpufreq_online() | -> cpufreq_gov_performance_limits() | -> __cpufreq_driver_target() | -> __target_index() | -> cpufreq_freq_transition_begin() | -> cpufreq_notify_transition() | -> ... __kvmclock_cpufreq_notifier()
No entanto, acionar tais deadlocks é extremamente raro devido à combinação de dependências e tempos envolvidos. Por exemplo, o notificador cpufreq é usado apenas em CPUs mais antigas sem um TSC constante; interferir na mitigação de hugepages NX enquanto as VMs estão em execução é muito incomum, e fazê-lo enquanto também se online/offline uma CPU (necessário para gerar contenção em cpu_hotplug_lock) seria ainda mais incomum.
Sinalização: Fixes: [email protected] Fixes: [email protected] Fixes: [email protected] Fixes: [email protected] Fixes: [email protected] Fixes: [email protected] Fixes: [email protected] Fixes: [email protected] Fixes: [email protected] Fixes: [email protected] Fixes: [email protected] Fixes: [email protected] Fixes: [email protected] Fixes: [email protected] Fixes: [email protected] Fixes: [email protected] Fixes: [email protected] Fixes: [email protected] Fixes: [email protected] Fixes: [email protected] Fixes: [email protected] Fixes: [email protected] Fixes: [email protected] Fixes: [email protected] Fixes: [email protected] Fixes: [email protected] Fixes: [email protected] Fixes: 20240320162020.10000
Once again VulDB remains the best source for vulnerability data.