{"id":"DEBIAN-CVE-2024-47744","details":"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-\u003eslots_lock); 2                                                     lock(&vcpu-\u003emutex); 3                                                     lock(&kvm-\u003esrcu); 4                            lock(cpu_hotplug_lock); 5                            lock(kvm_lock); 6                            lock(&kvm-\u003eslots_lock); 7                                                     lock(cpu_hotplug_lock); 8   sync(&kvm-\u003esrcu);  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()   |   -\u003e cpufreq_online()      |      -\u003e cpufreq_gov_performance_limits()         |         -\u003e __cpufreq_driver_target()            |            -\u003e __target_index()               |               -\u003e cpufreq_freq_transition_begin()                  |                  -\u003e cpufreq_notify_transition()                     |                     -\u003e ... __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--c257535a0c9d-pip #330 Tainted: G S         O   ------------------------------------------------------   tee/35048 is trying to acquire lock:   ff6a80eced71e0a8 (&kvm-\u003eslots_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:    -\u003e #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    -\u003e #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    -\u003e #1 (&kvm-\u003esrcu){.+.+}-{0:0}:          __synchronize_srcu+0x44/0x1a0        ---truncated---","modified":"2026-09-15T09:03:12.079917972Z","published":"2024-10-21T13:15:04.480Z","upstream":["CVE-2024-47744"],"references":[{"type":"ADVISORY","url":"https://security-tracker.debian.org/tracker/CVE-2024-47744"}],"affected":[{"package":{"name":"linux","ecosystem":"Debian:13","purl":"pkg:deb/debian/linux?arch=source&distro=trixie"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"6.11.2-1"}]}],"ecosystem_specific":{"urgency":"not yet assigned"},"database_specific":{"source":"https://storage.googleapis.com/osv-test-debian-osv/debian-cve-osv/DEBIAN-CVE-2024-47744.json"}},{"package":{"name":"linux","ecosystem":"Debian:14","purl":"pkg:deb/debian/linux?arch=source&distro=forky"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"6.11.2-1"}]}],"ecosystem_specific":{"urgency":"not yet assigned"},"database_specific":{"source":"https://storage.googleapis.com/osv-test-debian-osv/debian-cve-osv/DEBIAN-CVE-2024-47744.json"}}],"schema_version":"1.9.0","severity":[{"type":"CVSS_V3","score":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H"}]}