CVE-2026-64038

What it actually does

This is a Linux kernel use-after-free in the lm90 hardware monitoring driver. During probe failure, device unbind, or module removal, delayed work items for LM90-compatible temperature sensor alerts can remain runnable after the hwmon device object has already been unregistered and freed. If lm90_alert_work() or lm90_report_alarms() executes during that cleanup window, lm90_update_alarms() can dereference the freed data->hwmon_dev pointer. The likely technical result is a kernel crash, memory corruption, or undefined kernel behavior. Practical exploitation requires the vulnerable lm90 driver to be present and bound to compatible hardware or otherwise reachable through driver probing/unbinding behavior.

Why it matters to the business

Systems using affected Linux kernels with LM90-compatible hardware monitoring sensors may be vulnerable to instability or denial of service if the race condition is triggered. In operational environments, this can cause unexpected reboots, service interruption, monitoring gaps, and potential workload disruption. The current EPSS score is low, it is not listed in CISA KEV, and no public exploit maturity is indicated, so broad internet-scale exploitation is unlikely; however, kernel flaws should still be prioritized on systems where the affected driver is enabled because a crash at the kernel layer impacts the whole host.

How an attack unfolds

An attacker would need a way to influence the lifecycle of the lm90 hwmon driver or trigger error paths during device initialization, unbind, interrupt handling, or module removal. The vulnerable sequence occurs when devm-managed cleanup releases the hwmon device before queued delayed work has been fully cancelled. If an alert or report work item runs after the hwmon device is freed but before the work item is cancelled, the worker dereferences stale kernel memory. In the most realistic scenario, this results in a kernel oops, panic, or host denial of service. More advanced exploitation would require precise timing and a usable memory-reuse primitive in kernel space, and there is currently no indication of public weaponization.

How to fix it

Upgrade to a Linux kernel version that includes the upstream fix for the lm90 driver cleanup ordering. The fix cancels the relevant workers after hwmon registration and before interrupt handler registration, and adds a shutdown flag to prevent workers from being re-armed during device shutdown. If fixed vendor kernel versions are not yet published for a distribution, track the distribution's kernel security advisories and apply the first kernel update that includes the lm90 hwmon fix. Where immediate patching is not possible, reduce exposure by disabling or blacklisting the lm90 driver if it is not required, preventing untrusted users from loading/unloading kernel modules or rebinding devices, and limiting access to sysfs interfaces that can influence device driver binding. Operational mitigations should be tested carefully because disabling hwmon drivers may affect thermal monitoring and alerting.

How to confirm the fix worked

Confirm remediation by verifying that the running kernel package includes the lm90 fix from the upstream Linux kernel, not merely that an updated package is installed but not rebooted into. Check the active kernel with uname -r and compare it to the vendor advisory or patched build. Confirm whether the lm90 module is loaded with lsmod or modinfo, and whether LM90-compatible hwmon devices are present under /sys/class/hwmon. If source or build metadata is available, verify the lm90 driver includes the corrected cleanup ordering and shutdown guard. After patching, reboot into the fixed kernel and ensure hardware monitoring still functions without kernel warnings during driver unload/reload or device unbind/rebind tests in a controlled maintenance environment.

Typical attack path

1. Identify a Linux system running a vulnerable kernel with the lm90 hardware monitoring driver available and bound to compatible sensor hardware.
2. Obtain sufficient local privileges or device-control capability to trigger driver unbind, module unload, reprobe, probe failure, or related hardware-monitoring lifecycle events.
3. Cause or wait for LM90 alert/report delayed work to be queued while teardown or probe-failure cleanup is occurring.
4. Race the cleanup path so the hwmon device is freed before lm90 delayed work is cancelled.
5. Trigger execution of lm90_alert_work() or lm90_report_alarms(), causing lm90_update_alarms() to dereference a freed hwmon device pointer.
6. Achieve kernel crash, service disruption, or potentially undefined kernel memory corruption depending on timing and kernel configuration.

How to detect it

To determine whether this was already triggered, review kernel logs, persistent journal logs, crash dumps, and hardware-monitoring service logs for lm90 or hwmon-related failures. Useful sources include dmesg output, /var/log/kern.log, /var/log/messages, journalctl -k, kernel crash dump storage such as kdump/vmcore, and monitoring-agent logs that poll /sys/class/hwmon. Look for kernel oops or panic events mentioning lm90_update_alarms(), lm90_alert_work(), lm90_report_alarms(), use-after-free, KASAN, slab corruption, NULL or invalid pointer dereference, or crashes occurring during module unload, device unbind, or system shutdown. Also review audit logs or shell history for modprobe, rmmod, insmod, or sysfs driver unbind/bind operations involving lm90. Because this flaw does not produce a unique network indicator and may resemble a reliability crash, detection should focus on correlating kernel crash artifacts with lm90 driver lifecycle activity.

• lm90
• lm90_update_alarms
• lm90_alert_work
• lm90_report_alarms
• BUG: KASAN: use-after-free
• use-after-free in lm90_update_alarms
• kernel BUG
• kernel panic
• Oops:
• general protection fault
• Unable to handle kernel paging request
• hwmon
• /sys/class/hwmon
• /sys/bus/i2c/drivers/lm90
• modprobe lm90
• rmmod lm90
• insmod lm90
• unbind
• bind

What your security team should do

• Prioritize kernel updates for systems that use hardware monitoring sensors, embedded platforms, appliances, industrial systems, or servers where the lm90 driver is enabled.
• Inventory systems where the lm90 module is loaded or available, especially hosts exposing LM90-compatible temperature sensors through hwmon.
• Apply vendor kernel updates once available and ensure systems are rebooted into the fixed kernel.
• If patching is delayed and the driver is not required, consider blacklisting the lm90 module after validating operational impact.
• Restrict kernel module loading, driver unbinding, and access to sensitive sysfs device-management paths to trusted administrators only.
• Monitor kernel logs for oops, panic, KASAN, use-after-free, or lm90-related crashes, especially around module unload, device unbind, reprobe, or sensor alert activity.
• Treat repeated unexplained kernel crashes involving lm90 or hwmon as potential exploitation or reliability-triggering activity and preserve crash dumps for forensic review.