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.
Published: 2026-05-01
Score: 7.0 High
EPSS: n/a
KEV: No
Impact: n/a
Action: n/a
AI Analysis

Impact

The Linux kernel thermal core contains a race condition that allows a use‑after‑free when a thermal zone is unregistered during a resume operation. If an attacker can trigger thermal_pm_notify_complete() while a delayed work item is running, the cancel_delayed_work_sync() call may miss the work, and the thermal zone object can be freed while the work continues to execute. Running code that accesses freed memory can corrupt kernel state, potentially allowing local privilege escalation or remote code execution. The vulnerability is caused by a synchronization flaw that leads to a classic use‑after‑free (CWE‑416). The CVSS score of 7.0 indicates high severity, and the flaw also involves a race condition that satisfies CWE‑825.

Affected Systems

Any Linux system running a kernel that implements the thermal core module without the patch is affected. The patch moves the cancel_delayed_work() call to thermal_zone_pm_prepare() and adds a dedicated workqueue, but affected distributions are not specified in the advisory. System administrators should verify whether their kernel version includes static or dynamic thermal zone drivers.

Risk and Exploitability

With a CVSS score of 7.0 the vulnerability is considered high severity. The EPSS score is not available and the CVE is not listed in CISA’s KEV catalog, indicating that widespread exploitation is not currently observed. Attackers would need local kernel access to trigger the race, for example by interacting with removable devices that cause thermal zone unregister operations. Once the race is exploited, a local attacker could achieve kernel‑level code execution. The narrow exploitation window lowers the practical risk until the patch is applied.

Generated by OpenCVE AI on May 2, 2026 at 07:35 UTC.

Remediation

No vendor fix or workaround currently provided.

OpenCVE Recommended Actions

  • Upgrade the kernel to a version that includes the thermal core patch that moves cancel_delayed_work() to thermal_zone_pm_prepare() and introduces a dedicated workqueue for thermal events.
  • If an immediate kernel upgrade is not possible, disable unloading of thermal zone modules or ensure that thermal_zones remain resident during resume events to avoid the race.
  • Enable kernel hardening features such as SMEP, SMAP, and the SLUB allocator to add additional protection against use‑after‑free exploitation.

Generated by OpenCVE AI on May 2, 2026 at 07:35 UTC.

Tracking

Sign in to view the affected projects.

Advisories

No advisories yet.

History

Sat, 02 May 2026 00:15:00 +0000

Type Values Removed Values Added
Weaknesses CWE-825
References
Metrics threat_severity

None

cvssV3_1

{'score': 7.0, 'vector': 'CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H'}

threat_severity

Moderate


Sat, 02 May 2026 00:00:00 +0000

Type Values Removed Values Added
Weaknesses CWE-362
CWE-416

Fri, 01 May 2026 14:45:00 +0000

Type Values Removed Values Added
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.
Title thermal: core: Address thermal zone removal races with resume
First Time appeared Linux
Linux linux Kernel
CPEs cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
Vendors & Products Linux
Linux linux Kernel
References

Subscriptions

Linux Linux Kernel
cve-icon MITRE

Status: PUBLISHED

Assigner: Linux

Published:

Updated: 2026-05-01T14:14:30.177Z

Reserved: 2026-03-09T15:48:24.137Z

Link: CVE-2026-31731

cve-icon Vulnrichment

No data.

cve-icon NVD

Status : Awaiting Analysis

Published: 2026-05-01T15:16:35.683

Modified: 2026-05-01T15:24:14.893

Link: CVE-2026-31731

cve-icon Redhat

Severity : Moderate

Publid Date: 2026-05-01T00:00:00Z

Links: CVE-2026-31731 - Bugzilla

cve-icon OpenCVE Enrichment

Updated: 2026-05-02T07:45:37Z

Weaknesses