CVE-2026-31731
Awaiting Analysis Awaiting Analysis - Queue
Race Condition in Linux Kernel Thermal Subsystem Leads to Use-After-Free

Publication date: 2026-05-01

Last updated on: 2026-05-01

Assigner: kernel.org

Description
In the Linux kernel, the following vulnerability has been resolved: thermal: core: Address thermal zone removal races with resume Since thermal_zone_pm_complete() and thermal_zone_device_resume() re-initialize the poll_queue delayed work for the given thermal zone, the cancel_delayed_work_sync() in thermal_zone_device_unregister() may miss some already running work items and the thermal zone may be freed prematurely [1]. There are two failing scenarios that both start with running thermal_pm_notify_complete() right before invoking thermal_zone_device_unregister() for one of the thermal zones. In the first scenario, there is a work item already running for the given thermal zone when thermal_pm_notify_complete() calls thermal_zone_pm_complete() for that thermal zone and it continues to run when thermal_zone_device_unregister() starts. Since the poll_queue delayed work has been re-initialized by thermal_pm_notify_complete(), the running work item will be missed by the cancel_delayed_work_sync() in thermal_zone_device_unregister() and if it continues to run past the freeing of the thermal zone object, a use-after-free will occur. In the second scenario, thermal_zone_device_resume() queued up by thermal_pm_notify_complete() runs right after the thermal_zone_exit() called by thermal_zone_device_unregister() has returned. The poll_queue delayed work is re-initialized by it before cancel_delayed_work_sync() is called by thermal_zone_device_unregister(), so it may continue to run after the freeing of the thermal zone object, which also leads to a use-after-free. Address the first failing scenario by ensuring that no thermal work items will be running when thermal_pm_notify_complete() is called. For this purpose, first move the cancel_delayed_work() call from thermal_zone_pm_complete() to thermal_zone_pm_prepare() to prevent new work from entering the workqueue going forward. Next, switch over to using a dedicated workqueue for thermal events and update the code in thermal_pm_notify() to flush that workqueue after thermal_pm_notify_prepare() has returned which will take care of all leftover thermal work already on the workqueue (that leftover work would do nothing useful anyway because all of the thermal zones have been flagged as suspended). The second failing scenario is addressed by adding a tz->state check to thermal_zone_device_resume() to prevent it from re-initializing the poll_queue delayed work if the thermal zone is going away. Note that the above changes will also facilitate relocating the suspend and resume of thermal zones closer to the suspend and resume of devices, respectively.
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2026-05-01
Last Modified
2026-05-01
Generated
2026-05-07
AI Q&A
2026-05-01
EPSS Evaluated
2026-05-05
NVD
EUVD
Affected Vendors & Products
Showing 1 associated CPE
Vendor Product Version / Range
linux linux_kernel *
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-UNKNOWN
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?

This vulnerability exists in the Linux kernel's thermal management system. It involves a race condition during the removal of thermal zones when the system resumes from a suspended state. Specifically, the functions thermal_zone_pm_complete() and thermal_zone_device_resume() re-initialize delayed work items related to thermal zones, but the cancellation of these work items in thermal_zone_device_unregister() may miss some already running work. This can cause the thermal zone object to be freed prematurely while work items are still running, leading to a use-after-free condition.

There are two main scenarios where this happens: in the first, a work item is already running when thermal_pm_notify_complete() triggers re-initialization, causing cancel_delayed_work_sync() to miss it and resulting in use-after-free. In the second, a resumed work item runs after the thermal zone has been freed, also causing use-after-free.

The fix involves ensuring no thermal work items run during the critical period by moving cancellation calls earlier, using a dedicated workqueue for thermal events, flushing that workqueue properly, and adding state checks to prevent re-initialization of work on zones that are being removed.


How can this vulnerability impact me? :

This vulnerability can lead to use-after-free conditions in the Linux kernel's thermal management code. Such use-after-free bugs can cause system instability, crashes, or potentially allow an attacker to execute arbitrary code with kernel privileges if exploited.

Because thermal zones are critical for managing device temperatures, exploitation could also disrupt thermal management, potentially causing hardware overheating or damage.


What immediate steps should I take to mitigate this vulnerability?

To mitigate this vulnerability, ensure that no thermal work items are running when thermal_pm_notify_complete() is called. This involves moving the cancel_delayed_work() call from thermal_zone_pm_complete() to thermal_zone_pm_prepare() to prevent new work from entering the workqueue.

Additionally, switch to using a dedicated workqueue for thermal events and update the code in thermal_pm_notify() to flush that workqueue after thermal_pm_notify_prepare() has returned. This will handle any leftover thermal work already on the workqueue.

Also, ensure that thermal_zone_device_resume() includes a state check to prevent re-initializing the poll_queue delayed work if the thermal zone is being removed.


How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:

The provided information about CVE-2026-31731 does not include any details regarding its impact on compliance with common standards and regulations such as GDPR or HIPAA.


Ask Our AI Assistant
Need more information? Ask your question to get an AI reply (Powered by our expertise)
0/70
EPSS Chart