CVE-2026-89465: power: supply: rt9455: quiesce delayed work before teardown
In the Linux kernel, the following vulnerability has been resolved:
power: supply: rt9455: quiesce delayed work before teardown
The threaded IRQ handler can queue pwrrdywork, maxchargingtimework and battpresencework. pwrrdywork and battpresencework can also queue maxchargingtimework, while battpresencework can requeue itself.
rt9455remove() cancels maxchargingtimework before battpresencework. The latter can therefore queue maxchargingtimework after it has already been cancelled:
rt9455remove() workqueue cancel pwrrdywork cancel maxchargingtimework battpresencework queues maxchargingtimework cancel battpresencework return devres frees rt9455info maxchargingtimework dereferences rt9455info
The IRQ also remains registered until devres cleanup and can queue more work after any of the cancellation calls. If rt9455hwinit() fails after the IRQ has been requested, probe returns without cancelling work that may already have been queued. A pending callback can then access rt9455info after it has been freed.
Register rt9455cancelalldelayedworks() through devmaddactionorreset() right after devmpowersupplyregister(). devres invokes the action in reverse registration order, after the managed IRQ has been freed and before rt9455info is released, so the delayed works are drained in both rt9455remove() and the probe error path. Cancel pwrrdywork and battpresencework before maxchargingtimework because both can queue the latter.
This issue was found by an in-house static analysis tool.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Configuration
In the rt9455 driver: quiesce delayed work before teardown by canceling batt_presence_work, max_charging_time_work, and pwr_rdy_work before the driver info/devres objects are freed, and ensure delayed works are drained in both rt9455_remove() and the probe error path.
Linux kernel (power: supply: rt9455 driver) Quiesce/drain delayed works before teardown = Cancel batt_presence_work, max_charging_time_work, pwr_rdy_work and drain delayed works in rt9455_remove() and probe error paths
Event History
Frequently Asked Questions
When can the use-after-free condition occur?
It can occur during driver removal or when rt9455_hw_init() fails after the IRQ has been requested. Delayed work queued by the threaded IRQ handler can run after devres frees rt9455_info and dereference that freed state.
Why is canceling the delayed work individually insufficient?
batt_presence_work can queue max_charging_time_work after that work has already been canceled, and it can requeue itself. The IRQ remains registered until devres cleanup, so it can also queue additional work after cancellation calls.
What does the fix change?
The fix registers a routine to cancel all delayed work through devm_add_action_or_reset() immediately after devm_power_supply_register(). This ensures pending work is quiesced during teardown and probe-failure cleanup before rt9455_info is freed.