CVE-2026-64038 in Linux
Summary
by MITRE • 07/19/2026
In the Linux kernel, the following vulnerability has been resolved:
hwmon: (lm90) Stop work before releasing hwmon device
Sashiko reports:
In lm90_probe(), the devm action to cancel the alert_work and report_work (lm90_restore_conf) is registered in lm90_init_client() before devm_hwmon_device_register_with_info() is called.
Because devm executes cleanup actions in reverse order during module unbind or probe failure, the hwmon device is unregistered and freed first.
If lm90_alert_work() or lm90_report_alarms() runs in the window between the hwmon device being freed and the delayed works being cancelled, lm90_update_alarms() will dereference the freed data->hwmon_dev here.
Fix the problem by canceling the workers separately after registering the hwmon device and before registering the interrupt handler. This ensures that the workers are canceled after interrupts are disabled and before the hwmon device is released. Add "shutdown" flag to indicate that device shutdown is in progress to prevent workers from being re-armed.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 07/19/2026
The vulnerability in question affects the lm90 hardware monitoring driver within the Linux kernel, specifically addressing a race condition that could lead to use-after-free conditions during device cleanup operations. This issue demonstrates a classic improper resource management problem where the sequence of device initialization and cleanup actions creates an exploitable window. The flaw occurs when the hardware monitoring subsystem attempts to handle device removal or module unloading while background work items are still pending execution, resulting in potential memory corruption and system instability.
The technical implementation flaw stems from the incorrect ordering of device registration and work cancellation operations within the lm90_probe() function. During normal driver initialization, the lm90_init_client() function registers devm actions to cancel alert_work and report_work through lm90_restore_conf(), but this occurs before devm_hwmon_device_register_with_info() is invoked. According to the Linux kernel's device management framework, cleanup actions are executed in reverse order of registration, meaning that when a module unbinds or probe fails, the hwmon device gets unregistered and freed first, followed by the cancellation of the work items. This sequence creates a temporal gap where work functions can execute against already-freed memory structures.
The operational impact of this vulnerability extends beyond simple system instability to potentially allow privilege escalation or denial-of-service conditions in systems utilizing lm90 hardware monitoring devices. When lm90_alert_work() or lm90_report_alarms() execute during the cleanup window, they attempt to dereference data->hwmon_dev which points to freed memory, leading to kernel oops and system crashes. This type of vulnerability is particularly concerning in embedded systems or server environments where hardware monitoring is critical for system health management. The issue aligns with CWE-415: Double Free and CWE-416: Use After Free categories, as it represents a classic use-after-free scenario that can be exploited to corrupt kernel memory structures.
The mitigation strategy implemented addresses the root cause by reordering the initialization sequence to ensure proper cleanup timing. The fix involves canceling worker threads separately after the hwmon device registration but before registering the interrupt handler, which ensures that all work items are properly cancelled while interrupts remain disabled and before the hardware monitoring device is released. This approach follows established kernel development practices for managing device lifecycle operations and prevents the race condition by ensuring proper temporal ordering of operations. The addition of a "shutdown" flag serves as an additional protective measure to prevent workers from being re-armed during the shutdown sequence, effectively closing all potential attack vectors while maintaining the driver's functionality.
This vulnerability resolution demonstrates the importance of careful resource management in kernel-space drivers and aligns with ATT&CK technique T1068: Exploitation for Privilege Escalation by preventing exploitation through use-after-free conditions. The fix maintains system stability while ensuring that hardware monitoring capabilities remain functional, as confirmed by industry standards for kernel driver development practices. The solution represents a minimal yet effective patch that preserves existing functionality while eliminating the security risk through proper ordering of device management operations and appropriate synchronization mechanisms.