CVE-2026-31731 in Linux
الملخص
بحسب VulDB • 31/05/2026
في نواة لينكس، تم حل الثغرة التالية:
الجزء الأساسي للحرارة (thermal: core): معالجة سباقات الإزالة في منطقة الحرارة (thermal zone) أثناء الاستئناف (resume)
نظرًا لأن الدالتين `thermal_zone_pm_complete()` و `thermal_zone_device_resume()` تعيدان تهيئة عمل التأخير `poll_queue` لمنطقة الحرارة المحددة، فقد تفشل الدالة `cancel_delayed_work_sync()` الموجودة في `thermal_zone_device_unregister()` في التقاط بعض عناصر العمل التي بدأت بالفعل في التنفيذ، مما قد يؤدي إلى تحرير منطقة الحرارة بشكل مبكر [1].
هناك سيناريوان فاشلان كلاهما يبدأ بتشغيل `thermal_pm_notify_complete()` مباشرة قبل استدعاء `thermal_zone_device_unregister()` لأحد مناطق الحرارة.
في السيناريو الأول، يوجد عنصر عمل قيد التنفيذ بالفعل لمنطقة الحرارة المحددة عندما تستدعي `thermal_pm_notify_complete()` الدالة `thermal_zone_pm_complete()` لتلك المنطقة، ويستمر هذا العنصر في التنفيذ عندما تبدأ `thermal_zone_device_unregister()` في العمل. وبما أن عمل التأخير `poll_queue` قد أعيد تهيئته بواسطة `thermal_pm_notify_complete()`، فإن عنصر العمل قيد التنفيذ سيتم تفويته من قبل `cancel_delayed_work_sync()` في `thermal_zone_device_unregister()`، وإذا استمر في التنفيذ بعد تحرير كائن منطقة الحرارة، فسيحدث خطأ استخدام بعد التحرير (use-after-free).
في السيناريو الثاني، يعمل `thermal_zone_device_resume()` الذي تم إدراجه في قائمة الانتظار بواسطة `thermal_pm_notify_complete()` مباشرة بعد عودة `thermal_zone_exit()` التي تم استدعاؤها بواسطة `thermal_zone_device_unregister()`. يتم إعادة تهيئة عمل التأخير `poll_queue` بواسطة هذا الاستدعاء قبل استدعاء `cancel_delayed_work_sync()` من قبل `thermal_zone_device_unregister()`، لذا قد يستمر في العمل بعد تحرير كائن منطقة الحرارة، مما يؤدي أيضًا إلى حدوث خطأ استخدام بعد التحرير (use-after-free).
تم معالجة السيناريو الفاشل الأول عن طريق ضمان عدم وجود أي عناصر عمل حرارية قيد التنفيذ عند استدعاء `thermal_pm_notify_complete()`. ولتحقيق ذلك، تم أولاً نقل استدعاء `cancel_delayed_work()` من `thermal_zone_pm_complete()` إلى `thermal_zone_pm_prepare()` لمنع دخول أعمال جديدة إلى قائمة انتظار العمل (workqueue) في المستقبل. ثم، تم التبديل إلى استخدام قائمة انتظار عمل مخصصة لأحداث الحرارة، وتحديث الكود في `thermal_pm_notify()` لتصريف (flush) قائمة انتظار العمل هذه بعد عودة `thermal_pm_notify_prepare()`، مما سيتعامل مع جميع أعمال الحرارة المتبقية الموجودة بالفعل في قائمة انتظار العمل (حيث لن تفيد هذه الأعمال المتبقية في شيء على أي حال، لأن جميع مناطق الحرارة قد تم وضع علامة عليها على أنها معلقة).
تم معالجة السيناريو الفاشل الثاني عن طريق إضافة فحص لحالة `tz->state` في `thermal_zone_device_resume()` لمنع إعادة تهيئة عمل التأخير `poll_queue` إذا كانت منطقة الحرارة على وشك الإزالة.
جدير بالذكر أن التغييرات المذكورة أعلاه ستسهل أيضًا نقل عمليات تعليق واستئناف مناطق الحرارة لتصبح أقرب إلى عمليات تعليق واستئناف الأجهزة، على التوالي.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.