CVE-2026-90178 in Linux
Summary
by MITRE • 09/17/2026
In the Linux kernel, the following vulnerability has been resolved:
hwmon: (coretemp) Fix core_data leak on CPUs without PTS
pdata->core_data is allocated in init_temp_data() when the first core temp_data of a package is created, but it is only released from destroy_temp_data(), and only in the branch that handles the package temp_data.
Package temp_data is created solely when the CPU supports X86_FEATURE_PTS. On a CPU without it, coretemp_cpu_online() never calls coretemp_add_core() with pkg_flag set, so pdata->pkg_data stays NULL. coretemp_cpu_offline() then skips the removal of the package interface, destroy_temp_data() is never called for package data, and the array is still allocated when coretemp_device_remove() frees the platform data that pointed at it.
Release the array in coretemp_device_remove(). destroy_temp_data() sets pdata->core_data to NULL when it frees it, so the added kfree() is a no-op on CPUs that do have PTS.
Tested on an Intel Core i5-1135G7. The driver was instrumented to log every allocation and release of pdata->core_data, and the PTS check in coretemp_cpu_online() was patched out to emulate a CPU without package thermal support. Without this change the array was allocated and never released, and coretemp_device_remove() still saw a non-NULL pointer. With it the array is released and the pointer accounting balances. On an unmodified build the release still happens via the package temp_data and the added kfree() sees NULL, with no slab warnings over repeated module load and unload cycles.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 09/17/2026
The coretemp hardware monitoring driver in the Linux kernel contains a memory leak vulnerability affecting systems where the CPU does not support X86_FEATURE_PTS, which indicates package thermal status capabilities. This issue stems from an asymmetry in resource allocation and deallocation logic within the driver's initialization and removal routines. Specifically, during system boot or when cores come online, the function init_temp_data() allocates memory for pdata->core_data to store per-core temperature data structures whenever the first core of a package is processed. However, the corresponding cleanup routine destroy_temp_data(), which frees this allocated memory, was historically only invoked in code paths associated with package-level thermal data management.
The root cause lies in the conditional logic governing how different types of thermal data are handled based on CPU features. Package temp_data structures are exclusively created when a processor supports X86_FEATURE_PTS. On CPUs lacking this feature, the coretemp_cpu_online() function does not invoke coretemp_add_core() with the package flag set, resulting in pdata->pkg_data remaining NULL throughout the driver's lifecycle. Consequently, during system shutdown or module removal, the code path that triggers destroy_temp_data() for package data is never executed because it relies on the existence of pkg_data. This leaves the previously allocated core_data array orphaned in memory, as the general device removal function coretemp_device_remove() only frees the platform data container but does not explicitly free the internal core_data pointer if it was not handled by the package-specific cleanup path.
This vulnerability is classified under CWE-401, which describes a missing release of memory after effective usage. From an operational perspective, while this specific leak involves relatively small amounts of kernel heap memory per CPU package, repeated module load and unload cycles or frequent online/offline events can lead to gradual kernel memory exhaustion over time. In long-running systems with dynamic core management enabled, such as those utilizing power-saving states that frequently bring cores up and down, the accumulation of these unreleased allocations could contribute to increased pressure on the slab allocator. Although typically not immediately exploitable for privilege escalation or denial-of-service in a single instance, persistent memory leaks are considered poor security hygiene and can degrade system stability under sustained stress conditions involving thermal driver interactions.
The remediation involves modifying coretemp_device_remove() to explicitly check if pdata->core_data is non-NULL and freeing it using kfree(). This change ensures that the allocated array is released regardless of whether X86_FEATURE_PTS was supported by the hardware. The patch maintains backward compatibility because destroy_temp_data() already sets pdata->core_data to NULL after freeing it on systems with PTS support, rendering the additional free operation in coretemp_device_remove() a safe no-op for those configurations. Testing confirms that this fix resolves the leak on CPUs without package thermal support while preserving correct behavior and preventing slab warnings on modified builds where the feature is present.
From an attack surface perspective, this issue aligns with ATT&CK technique T1529, System Shutdown/Reboot, as it relates to improper resource cleanup during system state changes. While not a direct remote code execution vector, proper memory management in kernel drivers is critical for maintaining overall system integrity and preventing potential side-channel implications or stability issues that could be leveraged by local attackers seeking to destabilize the host environment through resource exhaustion. Administrators should ensure their kernels are updated with this fix applied to maintain robustness against such internal inconsistencies within hardware monitoring subsystems.