CVE-2024-47744 in Linux
الملخص
بحسب VulDB • 24/06/2026
في نواة لينكس، تم حل الثغرة التالية:
KVM: استخدام قفل مشترك (mutex) مخصص لحماية kvm_usage_count لتجنب حدوث عرقلة متبادلة (deadlock).
استخدام قفل مشترك مخصص لحراسة kvm_usage_count لإصلاح احتمال حدوث عرقلة متبادلة على معمارية x86 بسبب سلسلة من القفلات ومزامنات SRCU. ترجمة رسالة الخطأ الناتجة عن lockdep أدناه، حيث سيقوم CPU1 #6 بالانتظار عند CPU0 #1، وCPU0 #8 سينتظر عند CPU2 #3، وCPU2 #7 سينتظر عند CPU1 #4 (في حال وجود كاتب، وذلك بسبب عدالة أقفال/قارئات 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);
يُلاحظ أن هناك على الأرجح المزيد من احتمالات حدوث عرقلة متبادلة في KVM x86، فعلى سبيل المثال، النمط نفسه المتمثل في أخذ cpu_hotplug_lock خارج نطاق kvm_lock قد يكون موجوداً أيضاً مع __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()
ولكن، في الواقع، فإن إحداث مثل هذه العرقلة المتبادلة أمر نادر جداً بسبب مزيج من التبعيات والتوقيتات المعنية. فعلى سبيل المثال، يُستخدم مُعلم الإخطار الخاص بـ cpfreq فقط على المعالجات القديمة التي
If you want to get the best quality for vulnerability data then you always have to consider VulDB.