CVE-2026-43332

What it actually does

This is a Linux kernel use-after-free flaw in the thermal subsystem’s thermal zone device registration error path. If thermal_zone_device_register_with_trips() fails after a thermal zone device has already been registered, the kernel may free the thermal zone object before all references to its kobject have been released. A local user with the ability to interact with the relevant device/sysfs objects could potentially race the failed registration path and cause the kernel to access freed memory. Successful exploitation could allow local privilege escalation, kernel memory corruption, information disclosure, or denial of service through a kernel crash.

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. The CVSS score indicates high technical severity, but current public exploitation signals are low: EPSS is low, it is not listed in CISA KEV, it is not known to be used in ransomware campaigns, and no mature public exploit is indicated. The main business risk is that a compromised low-privileged account, container escape-adjacent scenario, or malicious local user could turn limited access into full system control or disrupt critical Linux workloads.

How an attack unfolds

An attacker first needs local code execution or an authenticated low-privileged shell on a vulnerable Linux system. They would then attempt to exercise the thermal subsystem registration and failure path while user space holds a reference to the thermal zone device’s kobject, commonly through sysfs exposure under the thermal device hierarchy. By winning the race between object reference handling and cleanup, the attacker may cause the kernel to free the thermal zone structure prematurely while it remains reachable through a lingering reference. The attacker would then attempt to shape kernel memory reuse so the stale reference points to attacker-influenced data, enabling kernel memory corruption. Depending on kernel configuration, mitigations, and exploit reliability, this may result in privilege escalation to root or a denial-of-service crash. There is currently no indication that this issue is being broadly exploited in the wild.

How to fix it

Upgrade to a Linux kernel build that includes the upstream fix adding the missing wait_for_completion() call in the thermal zone device registration error path. Because no exact fixed package versions were provided, use the latest stable kernel or distribution-maintained kernel package from the relevant Linux vendor and confirm that the fix for the thermal core registration error path is included. Reboot systems after installing the updated kernel so the patched kernel is active. Where immediate patching is not possible, reduce local attack surface by limiting shell access, restricting untrusted workloads, applying strong container isolation, enabling kernel hardening features, and monitoring or restricting access to thermal sysfs interfaces where operationally feasible.

How to confirm the fix worked

Confirm remediation by verifying that the running kernel, not only the installed package, is updated to a vendor release containing the thermal core fix. Use standard commands such as uname -a, package manager queries, and vendor advisory mapping to confirm the active kernel version. If building from source, verify that the thermal zone device registration error path waits for the thermal zone removal completion before freeing associated state. Validate that systems were rebooted into the patched kernel after update. Exposure can be assessed by inventorying Linux kernel versions across fleets and comparing them with distribution security advisories or upstream stable kernel changelogs for this fix.

Typical attack path

1. Obtain local access to a vulnerable Linux system as an unprivileged or low-privileged user.
2. Identify whether the running kernel includes the vulnerable thermal core registration error path.
3. Interact with thermal zone device interfaces, typically exposed through sysfs, to hold or race references to thermal zone kobjects.
4. Trigger a thermal zone device registration failure after registration has partially completed.
5. Exploit the missing completion wait to induce premature freeing of the thermal zone object while references still exist.
6. Attempt to reuse or corrupt freed kernel memory to gain elevated privileges or crash the kernel.

How to detect it

Detection of prior exploitation is difficult because successful use-after-free exploitation may leave few deterministic artifacts. Review kernel logs and centralized system logs for crashes, oops reports, BUG/WARNING traces, general protection faults, KASAN reports, or panic events involving the thermal subsystem, thermal zone devices, kobjects, sysfs, or use-after-free conditions. Useful log sources include journalctl, /var/log/kern.log, /var/log/messages, /var/log/syslog, crash dump repositories, kdump/vmcore analysis, EDR telemetry for local privilege escalation behavior, and audit logs showing unusual access to thermal device sysfs paths. Look for suspicious processes repeatedly reading, opening, or racing files under /sys/class/thermal/ around the time of kernel instability. Because there are no known public exploit-specific payload markers, prioritize behavioral evidence: unexpected root shells following low-privileged sessions, kernel crashes under local user activity, abnormal sysfs access patterns, and post-exploitation activity such as credential access, persistence creation, or tampering with security tooling.

• /sys/class/thermal/
• thermal_zone_device_register_with_trips
• thermal_release
• thermal_zone_device_unregister
• use-after-free
• KASAN: use-after-free
• BUG: KASAN
• general protection fault
• kernel BUG
• kernel panic
• Oops:
• thermal:
• thermal_zone

What your security team should do

• Prioritize patching multi-user Linux systems, shared compute platforms, developer workstations, bastion hosts, and systems that run untrusted local code or containers.
• Upgrade affected Linux kernels to vendor-supported fixed releases and reboot promptly to activate the patched kernel.
• Inventory running kernel versions across Linux assets and track remediation against the active kernel version, not just installed package state.
• Treat this as a local privilege escalation risk: investigate any prior low-privileged compromise on vulnerable systems as a potential precursor to kernel-level compromise.
• Monitor for kernel crashes, oops messages, or suspicious access patterns involving thermal sysfs paths, especially on systems where untrusted users have local access.
• Maintain normal hardening controls such as least-privilege access, container isolation, kernel lockdown where applicable, module signing, and prompt removal of unused local accounts.
• Because this issue is not currently KEV-listed and has low EPSS, prioritize it behind actively exploited internet-facing vulnerabilities, but do not defer patching on high-value or multi-tenant Linux systems.