CVE-2026-46021

What it actually does

This is a Linux kernel use-after-free and cleanup flaw in the thermal subsystem. Under specific error or race conditions involving thermal zone registration, unregistration, and governor changes through sysfs, the kernel may leave a thermal governor associated with a thermal zone after cleanup or may change the governor without holding the required thermal zone lock. A local authenticated user with access to the relevant thermal sysfs interfaces could potentially trigger a race that causes the kernel to reference freed memory, resulting primarily in a kernel crash or system denial of service. The published CVSS vector indicates local access, low attack complexity, low privileges required, no user interaction, and high availability impact, with no expected confidentiality or integrity impact.

Why it matters to the business

Successful exploitation can crash affected Linux systems or destabilize workloads that depend on kernel thermal management, causing service interruption, host reboots, failed jobs, or degraded availability. The risk is most relevant for systems where untrusted or semi-trusted local users, containers with unusual host sysfs exposure, appliance workloads, or device-management processes can interact with thermal zone governor settings. The vulnerability is not currently listed in CISA KEV, is not reported as ransomware-associated, has very low EPSS, and has no known public exploit maturity in the provided data, so it is generally a patch-cycle priority rather than an emergency internet-facing incident unless local multi-user exposure exists.

How an attack unfolds

An attacker first needs local access to an affected Linux system with sufficient permission to interact with thermal zone sysfs controls or influence thermal device registration and cleanup paths. They identify available thermal zones and governors exposed under /sys/class/thermal, then attempt to repeatedly change a thermal zone governor while registration or unregistration cleanup is occurring. Because the vulnerable code path can call thermal_set_governor() without the correct locking, a race may occur between sysfs-driven governor updates and thermal zone teardown. If timed successfully, the kernel may dereference a governor or thermal-zone object that has already been freed, producing a use-after-free condition. The most likely practical outcome is a kernel oops, panic, hang, or forced reboot, causing denial of service rather than data theft or privilege escalation based on the provided scoring and description.

How to fix it

Upgrade to a Linux kernel version that includes the upstream thermal core fix for governor cleanup and locking during thermal zone release and registration failure handling. If using a distribution kernel, apply the vendor-provided security or stable kernel update rather than relying only on upstream version numbers, because distributions frequently backport fixes without changing to the newest upstream release. Where immediate patching is not possible, reduce exposure by restricting write access to /sys/class/thermal/* governor or policy controls, avoiding unnecessary exposure of host /sys paths to containers, limiting local shell access to trusted administrators, and monitoring or disabling nonessential workflows that repeatedly reload thermal-related drivers or manipulate thermal governors. Because no exact fixed package versions were provided, consult the relevant Linux distribution security advisory, kernel changelog, or package metadata for the first kernel build containing the fix for this CVE.

How to confirm the fix worked

Confirm that the running kernel package includes the vendor fix for the thermal core governor cleanup issue. Validate both the installed kernel package and the actively booted kernel, since Linux systems may have patched packages installed but still be running an older kernel until reboot. Check the distribution advisory, changelog, or package notes for references to this CVE or to the thermal core fix involving thermal_set_governor(), thermal_release(), thermal_zone_device_unregister(), and thermal_zone_device_register_with_trips(). After patching and rebooting, verify that untrusted users and containers cannot write to host thermal governor sysfs controls unless explicitly required. Operational validation should include reviewing recent kernel logs for absence of thermal subsystem oops, panic, or use-after-free messages after normal thermal management activity.

Typical attack path

1. Obtain local authenticated access to a Linux system running an affected kernel.
2. Check whether thermal zones and governor controls are exposed under /sys/class/thermal/.
3. Determine whether the user context can read or write thermal zone policy or governor attributes, directly or through delegated tooling.
4. Repeatedly trigger thermal governor changes while thermal zone registration, unregistration, driver reload, suspend/resume, or hardware-management events occur.
5. Win the race condition in the thermal core cleanup path.
6. Cause the kernel to access freed memory, leading to a kernel oops, panic, system hang, or reboot.
7. Use the resulting crash to disrupt services or workloads running on the host.

How to detect it

Look for evidence of prior exploitation primarily in kernel and system logs, because this flaw is expected to manifest as a local denial-of-service condition rather than a durable file or network artifact. Relevant sources include dmesg output, journald kernel logs, /var/log/kern.log, /var/log/messages, /var/log/syslog, crash dump infrastructure such as kdump/vmcore, and endpoint telemetry showing writes to thermal sysfs attributes. Search for kernel oops, panic, general protection fault, slab use-after-free, KASAN, or BUG messages that reference the thermal subsystem, thermal_zone_device_unregister(), thermal_set_governor(), thermal_zone_device_register_with_trips(), thermal_release(), or governor updates. Also review auditd, EDR, shell history, and process execution telemetry for repeated or unusual writes to /sys/class/thermal/thermal_zone*/policy, /sys/class/thermal/thermal_zone*/governor, or related thermal zone attributes, especially shortly before a kernel crash or reboot. In containerized environments, investigate containers or processes with writable host /sys mounts and activity against thermal paths. Absence of these artifacts does not fully rule out exploitation, because a successful crash may truncate volatile logs unless persistent journaling, remote logging, or crash dumps are enabled.

• /sys/class/thermal/thermal_zone*/policy
• /sys/class/thermal/thermal_zone*/governor
• thermal_set_governor
• thermal_release
• thermal_zone_device_unregister
• thermal_zone_device_register_with_trips
• thermal: core
• thermal zone
• use-after-free
• KASAN: use-after-free
• BUG: kernel NULL pointer dereference
• kernel BUG at drivers/thermal
• general protection fault
• Oops:
• Kernel panic
• panic: Fatal exception
• echo * > /sys/class/thermal/thermal_zone
• /var/crash/vmcore
• /proc/vmcore

What your security team should do

• Inventory Linux systems and prioritize hosts that allow multiple local users, run untrusted workloads, expose host sysfs paths to containers, or perform hardware/thermal management operations.
• Apply the vendor-supported kernel update containing the thermal core fix, then reboot into the patched kernel.
• Verify the active kernel version after reboot using standard fleet management or endpoint inventory tooling; do not assume installation alone completed remediation.
• Restrict write access to /sys/class/thermal/ controls and remove unnecessary container mounts of host /sys, especially writable mounts.
• Review kernel logs for recent crashes, oopses, KASAN reports, or panic messages involving the thermal subsystem, thermal governors, or thermal zones.
• Treat unexpected host reboots or kernel panics on shared Linux systems as potential availability-impacting security events until logs confirm another cause.
• Because EPSS is very low and there is no KEV listing or known exploit maturity in the supplied data, schedule remediation according to normal kernel patch SLAs unless the system has high local-user exposure or critical availability requirements.