CVE-2026-97582: hwmon: (gpio-fan) Fix use-after-free in alarm work
In the Linux kernel, the following vulnerability has been resolved:
hwmon: (gpio-fan) Fix use-after-free in alarm work
fanalarmirqhandler() queues fandata->alarmwork, but nothing cancels it. fanalarmnotify() dereferences fandata and its hwmon device. On unbind, devres frees the interrupt, which only waits for the handler itself, and then releases the hwmon device and fandata, so a pending fanalarmnotify() can run after those frees.
Replace INITWORK() with devmworkautocancel(), registered before devmrequestirq(). The devres cleanup then frees the interrupt first, so no new work can be queued, and cancels the work while fandata and the hwmon device are still alive.
This issue was found by an in-house static analysis tool.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Configuration
Replace INIT_WORK() with devm_work_autocancel(), registering it before devm_request_irq(), so the work is canceled before the interrupt is freed and before fan_data and the hwmon device are released.
Linux kernel hwmon gpio-fan alarm_work initialization and cleanup = devm_work_autocancel() registered before devm_request_irq()
Event History
Frequently Asked Questions
When can this use-after-free occur?
It can occur when the gpio-fan driver is unbound while alarm work queued by fan_alarm_irq_handler() is still pending. The pending fan_alarm_notify() work may then access fan_data and the hwmon device after they have been released.
What conditions are needed to trigger the issue?
An alarm interrupt must queue alarm_work, followed by driver unbind before that queued work runs or is canceled. The issue is tied to the gpio-fan driver's alarm interrupt and its deferred notification work.
What is the mitigation if the fix cannot be applied immediately?
The provided data identifies unbinding the gpio-fan driver as the unsafe lifecycle event when alarm work may be pending. Avoid unbinding the driver in circumstances where its alarm interrupt could have queued work until a fixed kernel is deployed.
How does the fix prevent the problem?
The fix uses devm_work_autocancel() and registers it before devm_request_irq(). During cleanup, the interrupt is released first to prevent new work from being queued, then pending work is canceled while fan_data and the hwmon device still exist.