CVE-2026-89465

What it actually does

Use-after-free in the Linux kernel rt9455 power-supply (battery charger) driver: delayed work items (pwr_rdy_work, batt_presence_work, max_charging_time_work) and a still-registered threaded IRQ can run after rt9455_info is freed on device removal or a failed probe. That dangling kernel-heap dereference can panic the kernel or corrupt adjacent objects, enabling local denial of service and, with heap control, kernel-context code execution and privilege escalation (CVSS 8.4, C/I/A High, AV:L).

Why it matters to the business

Devices that ship the Richtek RT9455 charger stack (typically embedded, IoT, and mobile Linux) can crash when the driver is unbound or probe fails, and a local unprivileged user may fully compromise the host. The issue is not in CISA KEV, is not tied to ransomware, has no public exploit, and EPSS remains very low and flat (~0.0014 over 30 days), so internet-wide opportunistic risk is limited; residual risk is concentrated on products that load this driver and allow local access. Disclosure is about one month old, so unpatched vendor kernels remain the main operational gap.

How an attack unfolds

A local attacker on a system that binds the rt9455 driver induces teardown—module unload, sysfs unbind, hot-unplug, or a probe path that requests the IRQ then fails—while delayed works or the IRQ handler are still live. Because max_charging_time_work was cancelled before batt_presence_work (which can re-queue it) and the IRQ stayed registered until later devres cleanup, a callback can dereference freed rt9455_info. The resulting use-after-free is a classic kernel UAF primitive: crash for denial of service, or object reuse for privilege escalation. No named APT or campaign is associated, and exploit maturity is none; abuse would be local, timing-sensitive, and hardware/driver-specific rather than a remote wormable path.

How to fix it

Deploy a Linux kernel that contains the rt9455 teardown fix: register rt9455_cancel_all_delayed_works() with devm_add_action_or_reset() immediately after devm_power_supply_register(), free the IRQ before draining work, and cancel pwr_rdy_work and batt_presence_work before max_charging_time_work so neither can re-queue the latter; apply the same drain on the probe error path. Consume the corresponding stable or vendor backport—no per-package versions were published with this record. Until patched, do not unload or unbind rt9455, and restrict local logins and unprivileged module/sysfs access on appliances that use this charger IC.

How to confirm the fix worked

On each image, confirm the running kernel changelog or rt9455 driver source includes the managed cancel-all-delayed-works action and the corrected cancel order; verify with lsmod/sysfs whether rt9455 is present. After upgrade, bind/unbind or reboot the charger path and check dmesg/journal for oops, UAF, or workqueue warnings in rt9455. KASAN or similar debug kernels, if used in QA, should no longer report use-after-free on remove or failed probe.

Typical attack path

1. Obtain local (unprivileged) code execution or a shell on a Linux host whose kernel loads the rt9455 power-supply driver
2. Confirm the charger device is bound (power_supply/rt9455 class device or rt9455 module)
3. Trigger driver teardown or a probe-error race (unbind, module remove, or failed hw_init after IRQ request) so delayed works and the threaded IRQ outlive rt9455_info
4. Win the race so a work callback or IRQ-queued work runs against freed driver state
5. Use the kernel UAF for an oops/panic or, with heap reuse, escalate to root/kernel privileges

How to detect it

This is a local kernel UAF with no in-the-wild reporting; look for post-teardown crashes rather than network beacons. Review dmesg, journalctl -k, /var/log/kern.log, and crash dumps around rt9455 module unload, device unbind, or probe failure. Indicators include Oops/BUG/KASAN use-after-free or paging errors with rt9455, max_charging_time_work, batt_presence_work, pwr_rdy_work, or rt9455_remove on the stack, and workqueue execution after the driver device was released. Correlate with local sessions, rmmod/unbind, or charger hotplug. Absence of these logs does not prove non-exploitation if the host panicked without persistent logging.

• Oops or BUG with rt9455 in the backtrace
• KASAN: use-after-free in rt9455
• max_charging_time_work
• batt_presence_work
• pwr_rdy_work
• rt9455_remove
• Unable to handle kernel paging request near rt9455_info
• workqueue: max_charging_time_work
• modprobe/rmmod rt9455 immediately preceding a kernel oops

What your security team should do

• Inventory Linux images and embedded products for the rt9455 power-supply driver and prioritize kernel upgrades there first
• Apply vendor or stable kernels that drain all rt9455 delayed works via devm teardown; do not rely on module blacklist unless the hardware is unused
• Until patched, prevent unprivileged local access and block rt9455 unbind/rmmod on production devices
• Watch kernel logs for rt9455-related oops/UAF after device removal or probe failure; treat hits as suspected exploitation or instability
• Re-test charger bind/unbind and boot in CI after the kernel bump; KEV is false and EPSS is low, so schedule as a high-severity local kernel fix rather than an emergency internet-facing patch