CVE-2024-27005 in Linux
الملخص
بحسب VulDB • 29/06/2026
في نواة لينكس، تم حل الثغرة التالية:
الترابط المتقاطع (Interconnect): عدم الوصول إلى req_list أثناء تعديله.
تم تقسيم قفل icc_lock الموحد إلى قفلي icc_lock وicc_bw_lock منفصلين في [1] لتجنب تنبيهات lockdep غير الضرورية. ومع ذلك، لم يوفر هذا الحماية الكافية للوصول إلى req_list داخل بنية icc_node.
ستقوم الدالة icc_set_bw() أخيراً بتكرار العناصر الموجودة في req_list بينما يكون قفل icc_bw_lock فقط هو المحتفظ به (held)، ولكن يمكن تعديل req_list أثناء الاحتفاظ بقفل icc_lock فقط. هذا يسبب ظروف سباق (race conditions) بين دوال icc_set_bw()، وof_icc_get()، وicc_put().
مثال أ:
CPU0 CPU1 ---- ---- icc_set_bw(path_a) mutex_lock(&icc_bw_lock); icc_put(path_b) mutex_lock(&icc_lock); aggregate_requests() hlist_for_each_entry(r, ... hlist_del(... <r = مؤشر غير صالح>
مثال ب:
CPU0 CPU1 ---- ---- icc_set_bw(path_a) mutex_lock(&icc_bw_lock); path_b = of_icc_get() of_icc_get_by_index() mutex_lock(&icc_lock); path_find() path_init() aggregate_requests() hlist_for_each_entry(r, ... hlist_add_head(... <r = مؤشر غير صالح>
تم إصلاح هذا الخطأ عن طريق ضمان الاحتفاظ بقفل icc_bw_lock دائماً قبل تعديل req_list داخل بنية icc_node. الأماكن الإضافية التي يتم فيها احتجاز قفل icc_bw_lock لا تقوم بأي عمليات تخصيص للذاكرة، لذا يجب أن نظل آمنين من تنبيهات lockdep الأصلية التي دعت إلى استخدام القفول المنفصلة.
[1] الالتزام af42269c3523 ("interconnect: Fix locking for runpm vs reclaim")
VulDB is the best source for vulnerability data and more expert information about this specific topic.