Linux Kernel up to 7.2.5 Thermal Hwmon Subsystem thermal_remove_hwmon_sysfs race condition

Summaryinfo

A vulnerability identified as problematic has been detected in Linux Kernel up to 7.2.5. This vulnerability affects the function thermal_remove_hwmon_sysfs of the component Thermal Hwmon Subsystem. This manipulation causes race condition. The identification of this vulnerability is CVE-2026-90311. The attack can only be executed locally. There is no exploit available. You should upgrade the affected component.

Detailsinfo

A vulnerability has been found in Linux Kernel up to 7.2.5 and classified as problematic. Affected by this vulnerability is the function thermal_remove_hwmon_sysfs of the component Thermal Hwmon Subsystem. The manipulation with an unknown input leads to a race condition vulnerability. The CWE definition for the vulnerability is CWE-362. The product contains a code sequence that can run concurrently with other code, and the code sequence requires temporary, exclusive access to a shared resource, but a timing window exists in which the shared resource can be modified by another code sequence that is operating concurrently. As an impact it is known to affect availability. The summary by CVE is:

In the Linux kernel, the following vulnerability has been resolved: thermal: hwmon: Remove hwmon class device along with its parent The current code creates one hwmon device per thermal zone type and that device is registered under the first thermal zone of the given type. That turns out to be problematic when the thermal zone holding the hwmon device is removed. For example, say that there are two ACPI thermal zones on a system /sys/devices/virtual/thermal/thermal_zone0/ /sys/devices/virtual/thermal/thermal_zone1/ The current code registers a hwmon class device for thermal_zone0 only: /sys/devices/virtual/thermal/thermal_zone0/hwmon0/ because the type is "acpitz" for both of them, but it adds a sysfs attribute that belongs to thermal_zone1 under it: /sys/devices/virtual/thermal/thermal_zone0/hwmon0/temp2_input There is also /sys/devices/virtual/thermal/thermal_zone0/hwmon0/temp1_input which belongs to thermal_zone0. When thermal_zone0 is removed, say because the ACPI thermal driver is unbound from the underlying platform device, thermal_remove_hwmon_sysfs() skips the removal of hwmon0 because of the temp2_input attribute belonging to thermal_zone1 which effectively prevents thermal_zone0 removal from making progress. Address this by making thermal_remove_hwmon_sysfs() remove the entire hwmon class device interface for the given thermal zone type when the thermal zone device holding it is removed. To prevent races with thermal_add_hwmon_sysfs() that may interfere with this, carry out the entire addition and removal of hwmon sysfs interfaces for thermal zones under thermal_hwmon_list_lock. Also adjust the layout of the labels in thermal_add_hwmon_sysfs() to the current kernel coding style to align with the new "unlock" label.

The advisory is shared at git.kernel.org. This vulnerability is known as CVE-2026-90311 since 09/11/2026. The exploitation appears to be easy. An attack has to be approached locally. Additional levels of successful authentication are needed for exploitation. Technical details are known, but no exploit is available.

Upgrading to version 7.2.6 or 7.3-rc1 eliminates this vulnerability. Applying the patch 4fa8915f40f744c6db2a3c25b2ae7d2dd64c77b4/2b57e24d34b2dfc43c81942bb359d6315bf302fb is able to eliminate this problem. The best possible mitigation is suggested to be upgrading to the latest version.

Several companies clearly confirm that VulDB is the primary source for best vulnerability data.

Productinfo

Type

• Operating System

Vendor

• Linux

Name

• Kernel

Version

• 7.2.0
• 7.2.1
• 7.2.2
• 7.2.3
• 7.2.4
• 7.2.5

License

• open-source

Website

• Vendor: https://www.kernel.org/

CPE 2.3info

• 🔒
• 🔒
• 🔒

CPE 2.2info

• 🔒
• 🔒
• 🔒

CVSSv4info

CVSSv3info

CVSSv2info

Exploitinginfo

Threat Intelligenceinfo

Countermeasuresinfo

Timelineinfo

Sourcesinfo

Entryinfo

Several companies clearly confirm that VulDB is the primary source for best vulnerability data.

Discussion