CVE-2026-89465
nicheUse-after-free in Linux kernel rt9455 battery charger driver teardown
The Linux kernel's rt9455 (Richtek RT9455) power supply driver contains a use-after-free in its delayed workqueue handling during device removal or a failed probe. The threaded IRQ handler and the batt_presence_work callback can queue or requeue delayed work items after rt9455_remove() has already cancelled them, so a pending callback can dereference the rt9455_info structure after devres has freed it. A local attacker with the ability to trigger device unbinding or probe failure could theoretically turn this into memory corruption with high confidentiality, integrity, and availability impact per the CVSS 3.1 score of 8.4, though in practice this is primarily triggered by hot-unplug or driver teardown on systems using this charger IC. Only systems running kernels built with the rt9455 charger driver enabled are affected. No public proof of concept exists, the flaw is not in the CISA KEV catalog, and it was found by static analysis rather than observed exploitation.
What to do: Update to a kernel containing the fix, which registers rt9455_cancel_all_delayed_works() via devm_add_action_or_reset() so pending work is drained after the managed IRQ is freed and before rt9455_info is released. Check whether your kernel was built with CONFIG_CHARGER_RT9455 enabled — if it was not, the system is not affected. As a workaround on unpatched embedded systems, avoid unbinding or hot-removing the rt9455 charger device and monitor for power-supply workqueue crashes.
| Linux kernel (power supply rt9455 charger driver) | — |
Order-of-magnitude estimate by the model from install counts, market share and public scan data it knows; verify before quoting.
In the Linux kernel, the following vulnerability has been resolved: power: supply: rt9455: quiesce delayed work before teardown The threaded IRQ handler can queue pwr_rdy_work, max_charging_time_work and batt_presence_work. pwr_rdy_work and batt_presence_work can also queue max_charging_time_work, while batt_presence_work can requeue itself. rt9455_remove() cancels max_charging_time_work before batt_presence_work. The latter can therefore queue max_charging_time_work after it has already been cancelled: rt9455_remove() workqueue cancel pwr_rdy_work cancel max_charging_time_work batt_presence_work queues max_charging_time_work cancel batt_presence_work return devres frees rt9455_info max_charging_time_work dereferences rt9455_info The IRQ also remains registered until devres cleanup and can queue more work after any of the cancellation calls. If rt9455_hw_init() fails after the IRQ has been requested, probe returns without cancelling work that may already have been queued. A pending callback can then access rt9455_info after it has been freed. Register rt9455_cancel_all_delayed_works() through devm_add_action_or_reset() right after devm_power_supply_register(). devres invokes the action in reverse registration order, after the managed IRQ has been freed and before rt9455_info is released, so the delayed works are drained in both rt9455_remove() and the probe error path. Cancel pwr_rdy_work and batt_presence_work before max_charging_time_work because both can queue the latter. This issue was found by an in-house static analysis tool.
- Vector
- CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
In the news0 stories
No ingested article mentions this CVE yet.