CVE-2026-31731

What it actually does

CVE-2026-31731 is a Linux kernel use-after-free race in the thermal subsystem. During power-management resume and thermal zone unregistration, delayed work associated with a thermal zone can be reinitialized or continue running after the thermal zone object has been freed. If an attacker can locally influence the timing of suspend/resume, device removal, driver unload, or thermal-zone lifecycle events, the stale work item may dereference freed kernel memory. Successful exploitation could lead to kernel memory corruption, local privilege escalation, information disclosure, or denial of service through a kernel crash. The CVSS vector indicates local access with low attack complexity and low privileges required, with high confidentiality, integrity, and availability impact.

Why it matters to the business

Systems running affected Linux kernels may be exposed to local privilege escalation or crashes if an attacker already has low-privileged access. In practical terms, this can turn a limited shell, compromised service account, or container escape-adjacent foothold into full host compromise, depending on kernel configuration and exploitability. Availability impact is also material because failed exploitation attempts may panic or destabilize the host. This issue is not currently listed in CISA KEV, has no known public exploit maturity, and has a low, flat EPSS trend, so broad opportunistic exploitation is not indicated; however, kernel privilege-escalation flaws remain important for multi-user systems, shared compute, developer workstations, virtualization hosts, and servers where untrusted users or workloads can execute local code.

How an attack unfolds

An attacker first needs local code execution with low privileges on a vulnerable Linux system. They would then attempt to repeatedly trigger or race power-management completion/resume paths with thermal zone removal paths, such as through suspend/resume transitions, device hotplug, driver unloads, or subsystem behavior that causes thermal zones to be unregistered. The vulnerable condition occurs when thermal delayed work is reinitialized or continues executing while thermal_zone_device_unregister() proceeds to free the thermal zone object. If the attacker wins the race, a workqueue handler may operate on freed memory. With sufficient heap grooming and kernel exploit technique, this memory corruption may be shaped into arbitrary kernel code execution or privilege escalation; otherwise, the more likely visible outcome is a kernel oops, panic, or KASAN use-after-free report. There are no named threat actors or ransomware campaigns currently associated with exploitation of this issue.

How to fix it

Upgrade to a Linux kernel version that contains the upstream fix for the thermal core race condition. The fix prevents new thermal delayed work from being queued during PM prepare, flushes the dedicated thermal workqueue during PM notification handling, and prevents thermal_zone_device_resume() from reinitializing work for a thermal zone that is being removed. No exact fixed package versions were provided in the input, so use the kernel versions supplied by the relevant Linux distribution, appliance vendor, cloud image maintainer, or long-term-stable kernel branch. Where immediate patching is not possible, reduce exposure by limiting local shell access, restricting untrusted workloads, preventing unnecessary driver/module unload or device hotplug by unprivileged users, applying kernel lockdown and module-loading restrictions where compatible, and monitoring for kernel crashes or KASAN reports involving the thermal subsystem. Rebooting is typically required after kernel package updates to run the fixed kernel.

How to confirm the fix worked

Confirm remediation by verifying that the running kernel, not just the installed package, is at a vendor-fixed version. Use commands such as uname -r and distribution package tools to compare the active kernel against vendor advisories. Review changelogs or kernel source for the thermal core changes addressing thermal zone removal races with resume, including updates around thermal_zone_pm_prepare(), thermal_pm_notify(), thermal_zone_device_resume(), and dedicated thermal workqueue handling. Validate that systems have been rebooted into the patched kernel. For exposure review, inventory Linux hosts with thermal subsystem support and prioritize systems allowing local user access, untrusted code execution, containers, driver hotplug, or suspend/resume operations. If kernel sanitizers are enabled in test environments, attempt suspend/resume and thermal-zone lifecycle regression testing and confirm that no KASAN use-after-free or workqueue-related thermal subsystem warnings appear.

Typical attack path

1. Gain local execution on a vulnerable Linux host as an unprivileged or low-privileged user.
2. Identify that the running kernel includes the vulnerable thermal subsystem behavior.
3. Trigger repeated power-management resume or PM completion activity while provoking thermal zone unregistration through device lifecycle, driver, hotplug, or suspend/resume paths.
4. Attempt to win the race where delayed thermal work continues after the thermal zone object is freed.
5. Use heap grooming and kernel memory-corruption techniques to convert the use-after-free into privilege escalation, or cause a denial-of-service crash if exploitation is unsuccessful.
6. Establish elevated control of the host if kernel exploitation succeeds.

How to detect it

There are no public exploit-specific indicators available from the provided information, so detection should focus on evidence of attempted kernel exploitation or crashes in the affected thermal subsystem. Review kernel logs from journald, syslog, dmesg, crash dumps, pstore, netconsole, and centralized log collectors for use-after-free reports, KASAN findings, kernel oopses, panics, or general protection faults referencing thermal zone functions, delayed work, or workqueues. Look for sequences where suspend/resume or PM completion messages occur close in time to thermal zone removal, driver unload, device hotplug, or module activity. On systems with auditd or EDR telemetry, review local user activity around privileged operations that can affect power management, module loading/unloading, device binding/unbinding, or hotplug simulation. Absence of these artifacts does not prove non-exploitation, because a successful local kernel privilege escalation may leave minimal logs; however, failed attempts are likely to produce instability, kernel warnings, oopses, or crashes.

• BUG: KASAN: use-after-free
• KASAN: use-after-free
• use-after-free in thermal_zone_device_resume
• use-after-free in thermal_zone_device_unregister
• thermal_zone_device_resume
• thermal_zone_device_unregister
• thermal_zone_pm_complete
• thermal_zone_pm_prepare
• thermal_pm_notify_complete
• thermal_pm_notify_prepare
• thermal_zone_exit
• poll_queue
• workqueue: thermal
• general protection fault
• kernel NULL pointer dereference
• kernel BUG at drivers/thermal/thermal_core.c
• WARNING: CPU:
• Oops:
• Kernel panic - not syncing
• /sys/class/thermal/thermal_zone
• /sys/power/state

What your security team should do

• Prioritize patching Linux systems that allow local users, shared compute, CI/CD runners, developer access, container workloads, or untrusted code execution.
• Track distribution and vendor advisories for the first fixed kernel versions and ensure systems reboot into the fixed kernel after update.
• Because this is not KEV-listed, has no known public exploit, and has low EPSS, handle as important kernel hardening rather than an emergency internet-facing remote-exploitation event unless local threat exposure is high.
• Restrict unnecessary local privileges that could influence suspend/resume, device hotplug, driver unload, or kernel module loading.
• Enable or maintain hardening controls such as kernel lockdown, module signature enforcement, least-privilege sudo rules, and container isolation where operationally feasible.
• Monitor kernel logs for thermal subsystem crashes, KASAN use-after-free reports, general protection faults, and suspicious repeated suspend/resume or device lifecycle activity.
• Include this issue in vulnerability management reporting for Linux kernel assets and verify actual running kernel versions, not only installed package metadata.