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.
- Upgrade
Upgrade
debian/linuxto a version that resolves this vulnerability.Fixed in 6.12.111-1 - Upgrade
Upgrade
debian/linuxto a version that resolves this vulnerability.Fixed in 7.2.6-1 - Upgrade
Upgrade
debian/linux-6.12to a version that resolves this vulnerability.Fixed in 6.12.111-1~deb12u1 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 5.10.273 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 5.15.224 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 6.1.191 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 6.6.157 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 6.12.109 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 6.18.50 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 7.2.4 - Upgrade
Upgrade
debian/linuxto a version that resolves this vulnerability.Fixed in 6.12.115-2Fixed in 7.2.12-1Fixed in 7.2.15-1 - Upgrade
Upgrade
debian/linux-6.12to a version that resolves this vulnerability.Fixed in 6.12.113-1~deb12u1 - Upgrade
Upgrade
ubuntu/linux-hwe-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-42.42~24.04.1 - Upgrade
Upgrade
ubuntu/linux-riscv-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-42.42.1~24.04.1 - Upgrade
Upgrade
ubuntu/linuxto a version that resolves this vulnerability.Fixed in 7.0.0-42.42 - Upgrade
Upgrade
ubuntu/linux-awsto a version that resolves this vulnerability.Fixed in 7.0.0-1016.17 - Upgrade
Upgrade
ubuntu/linux-gcpto a version that resolves this vulnerability.Fixed in 7.0.0-1016.18 - Upgrade
Upgrade
ubuntu/linux-ibmto a version that resolves this vulnerability.Fixed in 7.0.0-1017.17 - Upgrade
Upgrade
ubuntu/linux-oem-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1017.17 - Upgrade
Upgrade
ubuntu/linux-oracleto a version that resolves this vulnerability.Fixed in 7.0.0-1015.16 - Upgrade
Upgrade
ubuntu/linux-riscvto a version that resolves this vulnerability.Fixed in 7.0.0-42.42.1 - Compensating control
In the rt9455 driver, register rt9455_cancel_all_delayed_works() through devm_add_action_or_reset() immediately after devm_power_supply_register(); ensure pwr_rdy_work and batt_presence_work are cancelled before max_charging_time_work, so delayed work is drained after the managed IRQ is freed and before rt9455_info is released.
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.