CVE-2026-89465: power: supply: rt9455: quiesce delayed work before teardown

[Greg Kroah-Hartman <gregkh@linuxfoundation.org>]

From: Greg Kroah-Hartman <gregkh@kernel.org>

Description
===========

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.

The Linux kernel CVE team has assigned CVE-2026-89465 to this issue.


Affected and fixed versions
===========================

	Issue introduced in 4.2 with commit e86d69dd786e94046b8f5be7df1b9a8226a40b2a and fixed in 6.12.109 with commit df67c7a2fff8414aa766b8cd5ffe11ec1ca27d02
	Issue introduced in 4.2 with commit e86d69dd786e94046b8f5be7df1b9a8226a40b2a and fixed in 6.18.50 with commit 1b9978433c61a9b46e48832a1ebceee1cf5c9eb4
	Issue introduced in 4.2 with commit e86d69dd786e94046b8f5be7df1b9a8226a40b2a and fixed in 7.2.4 with commit 7323e562f6961e4b7bce3225cde4ecbc78260deb
	Issue introduced in 4.2 with commit e86d69dd786e94046b8f5be7df1b9a8226a40b2a and fixed in 7.3-rc1 with commit 3e7a1ebc32fad5a558254a478efd401c17a24381

Please see https://www.kernel.org for a full list of currently supported
kernel versions by the kernel community.

Unaffected versions might change over time as fixes are backported to
older supported kernel versions.  The official CVE entry at
	https://cve.org/CVERecord/?id=CVE-2026-89465
will be updated if fixes are backported, please check that for the most
up to date information about this issue.


Affected files
==============

The file(s) affected by this issue are:
	drivers/power/supply/rt9455_charger.c


Mitigation
==========

The Linux kernel CVE team recommends that you update to the latest
stable kernel version for this, and many other bugfixes.  Individual
changes are never tested alone, but rather are part of a larger kernel
release.  Cherry-picking individual commits is not recommended or
supported by the Linux kernel community at all.  If however, updating to
the latest release is impossible, the individual changes to resolve this
issue can be found at these commits:
	https://git.kernel.org/stable/c/df67c7a2fff8414aa766b8cd5ffe11ec1ca27d02
	https://git.kernel.org/stable/c/1b9978433c61a9b46e48832a1ebceee1cf5c9eb4
	https://git.kernel.org/stable/c/7323e562f6961e4b7bce3225cde4ecbc78260deb
	https://git.kernel.org/stable/c/3e7a1ebc32fad5a558254a478efd401c17a24381