CVE-2026-64038: hwmon: (lm90) Stop work before releasing hwmon device
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.
Security readout for executives and security teams
Plain-English summary
CVE-2026-64038 is a Linux kernel flaw in the lm90 hardware-monitoring driver. During driver shutdown or failed setup, background work can run after the hardware-monitor device has already been freed, causing a use-after-free. Business impact is most likely system instability on affected Linux hosts using this driver; broader impact is not established by the sources.
Executive priority
Treat as a focused kernel maintenance issue, not an emergency based on current evidence. Patch through normal kernel update processes, with higher priority for infrastructure that uses lm90 hardware monitoring or allows driver lifecycle changes.
Technical view
The bug is caused by devm cleanup ordering in lm90_probe(): delayed alert/report work was cancelled after the hwmon device could be unregistered and freed. If lm90_alert_work() or lm90_report_alarms() runs in that window, lm90_update_alarms() can dereference data->hwmon_dev after free. The kernel fix cancels workers in the safer order and adds a shutdown flag to prevent re-arming.
Likely exposure
Exposure appears limited to Linux systems running affected kernel versions or commits where the lm90 hwmon driver is present and active. The source bundle lists Linux as affected, including versions 6.0, 0, 6.18.34, 7.0.11, and 7.1, but does not provide a complete distribution-level affected-version matrix.
Exploitation context
The source bundle does not report active exploitation, public exploit code, KEV listing, or a CVSS score. The described trigger window occurs during module unbind or probe failure while delayed work is still able to run. Practical exploitability is unclear from the provided evidence.
Researcher notes
The key research point is lifecycle ordering: devm cleanup ran in reverse order, freeing hwmon_dev before delayed works were cancelled. The fix moves worker cancellation after hwmon registration and before interrupt registration, then uses a shutdown flag to stop re-arming. No exploitability assessment is included in the bundle.
Mitigation direction
Apply vendor kernel updates containing the referenced stable commits.
Prioritize systems using the lm90 hwmon driver or related sensor hardware.
Check Linux distribution advisories for backported fixed kernel packages.
If patching is delayed, review whether the lm90 driver is needed.
Avoid inventing compensating controls; follow vendor guidance when available.
Validation and detection
Confirm the running kernel includes one of the referenced stable fixes.
Inventory hosts for loaded or configured lm90 hwmon driver usage.
Check distribution kernel changelogs for CVE-2026-64038 or lm90 fix references.
Review kernel logs for lm90 driver probe, unbind, or alarm activity.
Track whether CVSS, CWE, or vendor advisories are later published.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cve · low confidence lookup
CVE-2026-64038 mapping review
Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
0CVSS vectors
3Timeline events
0ADP providers
4Source links
Vulnerability timeline
Timeline events are normalized from CVE metadata, CNA source timelines, ADP timelines, and KEV metadata when present.
CVE reservedCVE Program
The CVE ID was reserved by the assigning CNA.
CVE publishedCVE Program
The CVE record was published.
Jul 19, 2026, 15:39 UTC (UTC+00:00)
CVE updatedCVE Program
The CVE record metadata indicates this as the latest update time.