CVE-2026-64213

What it actually does

This is a race condition in the Linux kernel lm90 hardware monitoring driver. The lm90_alert() interrupt/SMBus alert handler updates the device configuration register without taking the same hwmon_lock used by sysfs write paths. If an LM90-compatible sensor alert occurs while a privileged local process is modifying hwmon settings through sysfs, the sysfs path can overwrite the alert handler’s configuration change and unintentionally re-enable the alert line while the alarm condition remains active. The practical result is an interrupt storm, potentially causing high CPU usage, degraded system responsiveness, watchdog resets, or denial of service on systems using the affected driver and hardware.

Why it matters to the business

The main risk is availability disruption on Linux systems that use LM90-compatible temperature sensor hardware. Affected systems may experience CPU saturation, instability, or outages if the race is triggered, which can impact production workloads, embedded appliances, monitoring infrastructure, or hardware platforms that rely on stable thermal telemetry. The issue is not currently listed in CISA KEV, is not known to be used in ransomware campaigns, and has a low EPSS score, so broad internet-scale exploitation is unlikely; however, patching should still be prioritized for systems where the lm90 driver is loaded or hardware monitoring is operationally important.

How an attack unfolds

An attacker would first need access to a system using the Linux lm90 hwmon driver and the ability to cause or coincide with writes to the driver's sysfs configuration attributes. In a typical local exploitation scenario, the attacker repeatedly changes exposed hwmon settings while an LM90-compatible device is in an active alarm state or while an alert is generated. Because the alert handler lacks proper locking, the alert path and sysfs write path can update the same configuration state concurrently. If the timing is successful, the sysfs writer restores stale configuration data and re-enables the hardware alert line even though the alarm condition is still present. The system can then receive repeated interrupts, creating an interrupt storm that consumes CPU and may degrade or halt normal operation. There is no indication from the provided data of public exploit code, KEV exploitation, ransomware use, or remote exploitation.

How to fix it

Apply a vendor-supplied Linux kernel update that includes the lm90 driver fix for the missing lock in lm90_alert(), specifically the patch described as "hwmon: (lm90) Add lock protection to lm90_alert". Because no exact fixed package versions were provided, use the fixed kernel versions published by the relevant Linux distribution, appliance vendor, cloud image provider, or embedded platform maintainer. Reboot into the updated kernel after installation and verify the running kernel, not only the installed package, has changed. Where immediate patching is not possible, consider temporary mitigations: unload or blacklist the lm90 module if the hardware monitoring function is not required; restrict administrative access capable of writing to /sys/class/hwmon paths; disable unneeded SMBus alert functionality if supported by the platform; and monitor for interrupt storms or abnormal IRQ rates. Mitigations may reduce risk but should not be treated as a substitute for the kernel fix on affected systems.

How to confirm the fix worked

Confirm exposure by checking whether the lm90 driver is present and loaded, for example with lsmod, modinfo, or by inspecting /sys/bus/i2c/drivers/lm90 and /sys/class/hwmon. Confirm remediation by verifying the system is running a vendor kernel version that includes the lm90_alert locking fix, or by reviewing the kernel source/package changelog for the patch "hwmon: (lm90) Add lock protection to lm90_alert". After reboot, confirm the active kernel with uname -r and package manager tooling. Operationally validate that systems no longer show repeated SMBus alert or IRQ storm behavior during normal hwmon activity. Any race-condition stress testing should be performed only in non-production environments because successful triggering may degrade system availability.

Typical attack path

1. Identify a Linux system where the lm90 hwmon driver is present, loaded, and bound to compatible sensor hardware.
2. Obtain local privileges sufficient to write to lm90-related sysfs hwmon attributes, typically requiring root or equivalent administrative access.
3. Create or wait for an active sensor alert condition on the LM90-compatible device.
4. Repeatedly modify hwmon configuration attributes through sysfs while the alert handler is executing.
5. Win the race between the sysfs write path and lm90_alert() so stale configuration state is restored.
6. Cause the hardware alert line to be re-enabled while the alarm remains active.
7. Trigger an interrupt storm that consumes CPU resources and degrades or denies service.

How to detect it

To determine whether the flaw may have been triggered, focus on evidence of interrupt storms and concurrent hwmon configuration writes. Review kernel logs from journald, dmesg, rsyslog, or centralized log collection for repeated SMBus alert, lm90, IRQ storm, or disabled IRQ messages. Check system telemetry for sudden CPU spikes in kernel time, high kworker usage, watchdog resets, unexpected reboots, thermal sensor alert loops, or rapidly increasing interrupt counters in /proc/interrupts. If auditd, eBPF, EDR, or file integrity monitoring captured sysfs writes, look for privileged processes repeatedly writing under /sys/class/hwmon/ or lm90-bound device paths near the time of the interrupt storm. Also review package and reboot history to determine whether the system was still running an unfixed kernel when the symptoms occurred. Absence of these artifacts does not prove non-exploitation, because many Linux systems do not log sysfs writes by default.

• lm90
• /sys/class/hwmon/
• /sys/bus/i2c/drivers/lm90
• /proc/interrupts
• smbus alert
• SMBus alert
• interrupt storm
• nobody cared
• Disabling IRQ #
• irq storm
• kworker
• hwmon
• update_interval
• temp1_max
• temp2_max
• temp1_crit
• temp2_crit

What your security team should do

• Inventory Linux systems, appliances, and embedded platforms that load the lm90 kernel module or expose LM90-compatible hwmon devices.
• Prioritize kernel updates for systems where lm90 is loaded, where thermal monitoring is critical, or where local administrative access is shared among multiple operators or automation tools.
• Apply vendor kernel updates and reboot into the fixed kernel; do not rely on installed-but-not-running kernel packages.
• If patching is delayed, disable or unload the lm90 driver where it is not operationally required, and restrict write access to hwmon sysfs attributes to trusted administrators only.
• Add monitoring for sudden increases in IRQ rate, kworker CPU consumption, SMBus alert messages, and kernel logs indicating interrupt storms.
• Review privileged automation, monitoring agents, and scripts that write to /sys/class/hwmon to ensure they are necessary and controlled.
• Because this issue is not KEV-listed, has no known ransomware use, and has low EPSS, treat it as a targeted availability risk rather than an emergency internet-facing remote-code-execution event.