CVE-2026-89464: power: supply: twl4030_charger: cancel workers via devm
In the Linux kernel, the following vulnerability has been resolved:
power: supply: twl4030charger: cancel workers via devm
bci is devm-allocated. Two workers (bci->work and bci->currentworker) dereference it. twl4030bciremove() disables charging and masks interrupts. It cancels neither worker. A worker pending at remove() can run after devm frees bci.
The USB transceiver comes from devmusbgetphybynode(). devm unregisters its notifier only after remove() returns. A cancelworksync() in remove() can then race a notifier reschedule. devmworkautocancel() and devmdelayedworkautocancel() avoid that. They cancel the workers during devm release, before bci is freed.
The currentworker is registered first, since devm will cancel in reverse order and bci->work can reschedule currentworker.
[Move comment about order into the commit message]
Event History
Frequently Asked Questions
Which deployments are exposed to this issue?
Systems using the Linux twl4030_charger power-supply driver are exposed when the driver is removed while either of its workers is pending. The risk occurs during device removal or driver teardown, not merely from normal charging operation.
What condition triggers the use-after-free?
A pending bci->work or bci->current_worker can execute after remove() returns and devm frees the devm-allocated bci structure. Those workers dereference bci, producing the use-after-free condition.
Why is cancel_work_sync() in the remove path not sufficient?
The USB transceiver notifier remains registered until after remove() returns, so it can reschedule a worker after cancel_work_sync() runs. The resolved approach uses devm-managed worker cancellation during devm release, before bci is freed.
How does the fix prevent worker rescheduling during teardown?
It uses devm_work_autocancel() and devm_delayed_work_autocancel() so the workers are cancelled as part of managed-resource release. current_worker is registered first so reverse-order cleanup cancels bci->work before current_worker, preventing bci->work from rescheduling it.