CVE-2026-64213 in Linux
Summary
by MITRE • 07/24/2026
In the Linux kernel, the following vulnerability has been resolved:
hwmon: (lm90) Add lock protection to lm90_alert
Sashiko reports:
lm90_alert() executes in the smbus alert context and calls lm90_update_confreg() to disable the hardware alert line, without acquiring hwmon_lock.
Concurrently, sysfs write operations (such as lm90_write_convrate) hold the hwmon_lock, temporarily modify data->config, and then restore it.
If an alert interrupt occurs concurrently with a sysfs write, the sysfs path will overwrite the alert handler's modifications to data->config and the hardware register.
This unintentionally re-enables the hardware alert line while the alarm is still active, causing an interrupt storm.
Add the missing lock to lm90_alert() to solve the problem.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 07/24/2026
The vulnerability in question involves a race condition within the Linux kernel's hardware monitoring subsystem, specifically affecting the lm90 driver which manages temperature sensors. This issue demonstrates a classic concurrency problem where multiple execution paths access shared data structures without proper synchronization mechanisms. The lm90_alert() function operates within the SMBus alert context and attempts to modify hardware configuration registers to disable the alert line, while other system paths like lm90_write_convrate execute in sysfs write operations that hold exclusive hwmon_lock access. The fundamental flaw occurs when these concurrent execution contexts attempt to modify the same data structure without proper mutual exclusion, creating a scenario where the alert handler's modifications can be overwritten by the sysfs write operation.
The technical implementation of this vulnerability stems from improper locking protocols within the hardware monitoring framework. When lm90_alert() executes, it modifies the configuration register to disable the hardware alert line but fails to acquire the hwmon_lock that protects the shared data structure. Meanwhile, sysfs write operations such as lm90_write_convrate hold the hwmon_lock for the duration of their execution, temporarily altering data->config and subsequently restoring it to its original state. This creates a temporal window where concurrent execution can result in inconsistent hardware states, particularly when an alert interrupt occurs simultaneously with a sysfs write operation.
The operational impact of this vulnerability manifests as an interrupt storm condition that severely degrades system performance and reliability. When the hardware alert line gets unintentionally re-enabled while an active alarm condition persists, the system experiences continuous interrupt generation, effectively creating a denial-of-service scenario for the hardware monitoring subsystem. This behavior can lead to excessive CPU utilization, system instability, and potentially prevent other critical monitoring functions from operating correctly. The vulnerability affects systems that rely on lm90 temperature sensors for hardware health monitoring, particularly in server environments where continuous temperature monitoring is essential for preventing hardware failures.
This vulnerability aligns with CWE-362, which specifically addresses race conditions occurring due to insufficient locking mechanisms. From an ATT&CK framework perspective, this represents a privilege escalation vector through system instability manipulation, potentially allowing adversaries to cause resource exhaustion or system crashes. The fix implemented involves adding the missing hwmon_lock acquisition to the lm90_alert() function to ensure atomic access to shared configuration data structures. This modification follows established kernel programming practices for protecting concurrent access to hardware registers and maintaining consistent device states. The resolution directly addresses the root cause by ensuring that all modifications to the configuration register occur within proper synchronization boundaries, preventing the overwrite scenario that led to the interrupt storm condition.
The broader implications extend beyond this specific driver to highlight potential security concerns in embedded systems where hardware monitoring plays a critical role in system integrity. This vulnerability demonstrates how seemingly minor locking oversights can lead to significant operational impacts, particularly in environments where hardware alerts are used for critical system health monitoring and fault detection. Proper implementation of concurrency controls in kernel drivers remains essential for maintaining system stability and preventing cascading failures that could affect overall platform reliability. The fix reinforces the principle that all shared data access must be protected by appropriate synchronization primitives to prevent race conditions that can compromise system behavior and security posture.