CVE-2024-47744

published 2024-10-21

CVE-2024-47744: In the Linux kernel, the following vulnerability has been resolved: KVM: Use dedicated mutex to protect kvm_usage_count to avoid deadlock Use a dedicated mutex…

Priority P4 19 medium 5.5 CVSS 3.1

AV L AC L PR L UI N S U C N I N A H

In the Linux kernel, the following vulnerability has been resolved:

KVM: Use dedicated mutex to protect kvm_usage_count to avoid deadlock

Use a dedicated mutex to guard kvm_usage_count to fix a potential deadlock
on x86 due to a chain of locks and SRCU synchronizations. Translating the
below lockdep splat, CPU1 #6 will wait on CPU0 #1, CPU0 #8 will wait on
CPU2 #3, and CPU2 #7 will wait on CPU1 #4 (if there's a writer, due to the
fairness of r/w semaphores).

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, there are likely more potential deadlocks in KVM x86, e.g. the same
pattern of taking cpu_hotplug_lock outside of kvm_lock likely exists with
__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()

But, actually triggering such deadlocks is beyond rare due to the
combination of dependencies and timings involved. E.g. the cpufreq
notifier is only used on older CPUs without a constant TSC, mucking with
the NX hugepage mitigation while VMs are running is very uncommon, and
doing so while also onlining/offlining a CPU (necessary to generate
contention on cpu_hotplug_lock) would be even more unusual.

The most robust solution to the general cpu_hotplug_lock issue is likely
to switch vm_list to be an RCU-protected list, e.g. so that x86's cpufreq
notifier doesn't to take kvm_lock. For now, settle for fixing the most
blatant deadlock, as switching to an RCU-protected list is a much more
involved change, but add a comment in locking.rst to call out that care
needs to be taken when walking holding kvm_lock and walking vm_list.

WARNING: possible circular locking dependency detected
6.10.0-smp--c257

Affected

17 ranges

Vendor	Product	Version range	Fixed in
debian	linux	< linux 6.11.2-1 (forky)	linux 6.11.2-1 (forky)
linux	linux	—	—
linux	linux	>= 0bf50497f03b3d892c470c7d1a10a3e9c3c95821 < 4777225ec89f52bb9ca16a33cfb44c189f1b7b47	4777225ec89f52bb9ca16a33cfb44c189f1b7b47
linux	linux	>= 0bf50497f03b3d892c470c7d1a10a3e9c3c95821 < a2764afce521fd9fd7a5ff6ed52ac2095873128a	a2764afce521fd9fd7a5ff6ed52ac2095873128a
linux	linux	>= 0bf50497f03b3d892c470c7d1a10a3e9c3c95821 < 760a196e6dcb29580e468b44b5400171dae184d8	760a196e6dcb29580e468b44b5400171dae184d8
linux	linux	>= 0bf50497f03b3d892c470c7d1a10a3e9c3c95821 < 44d17459626052a2390457e550a12cb973506b2f	44d17459626052a2390457e550a12cb973506b2f
linux	linux_kernel	>= 0 < 6.11.2-1	6.11.2-1
linux	linux_kernel	>= 0 < 6.11.2-1	6.11.2-1
linux	linux_kernel	>= 0 < 6.8.0-54.56	6.8.0-54.56
linux	linux_kernel	>= 0 < 6.11.0-18.18	6.11.0-18.18
linux	linux_kernel	>= 6.11 < 6.11.2	6.11.2
linux	linux_kernel	>= 6.3 < 6.6.54	6.6.54
linux	linux_kernel	>= 6.7 < 6.10.13	6.10.13
msrc	azl3_kernel_6.6.51.1-5_on_azure_linux_3.0	—	—
msrc	azl3_kernel_6.6.56.1-5_on_azure_linux_3.0	—	—
msrc	azure_linux_3.0_arm	—	—
msrc	azure_linux_3.0_x64	—	—

CVSS provenance

nvd v3.1 5.5 MEDIUM CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

osv 8.8 HIGH

vendor_ubuntu 8.8 HIGH

vendor_debian 5.5 LOW

vendor_msrc 5.5 MEDIUM

vendor_redhat 5.5 MEDIUM

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.

CWE-667