CVE-2026-89472

What it actually does

The Linux kernel charger-manager power-supply driver has a use-after-free from inverted lifetime ordering between regulator consumer handles and power_supply sysfs. Probe exposes sysfs (power_supply_register) before regulator_get, so userspace can reach the externally_control attribute while handles are not yet valid. On remove and the err_reg_extcon error path, regulator_put() runs before power_supply_unregister() and try_charger_enable(cm, false). A concurrent write to externally_control can invoke charger_externally_control_store() → try_charger_enable() against already-freed regulator consumers; disable-on-remove can do the same. The result is kernel memory corruption with High confidentiality, integrity, and availability impact (local privilege escalation, information leak, or panic). A related extcon-notifier dereference of the same handles is not fixed by this change.

Why it matters to the business

Linux systems that load charger-manager—typical on embedded, IoT, industrial, and some mobile or single-board platforms—can be crashed or, if the UAF is weaponized, fully compromised by a local low-privileged user or container that can write sysfs and race driver teardown. Confidentiality, integrity, and availability of the host are all at risk because a kernel UAF can become arbitrary kernel read/write. This issue is not in CISA KEV, is not associated with ransomware, has exploit maturity None, and EPSS is low and flat (~0.00163 over 30 days), so widespread remote or automated exploitation is unlikely. Residual business risk is concentrated in fleets that allow untrusted local users, nested tenants, or hot-unbind of power-supply devices, and in products still running unpatched kernels more than a month after publication.

How an attack unfolds

A local, low-privileged attacker on a host where charger-manager is bound identifies the charger power_supply sysfs tree and the externally_control attribute. They induce or wait for driver teardown (unbind, module removal, or a probe failure) while writing that attribute so charger_externally_control_store() runs after regulator_put() but before power_supply_unregister(). try_charger_enable() then dereferences freed regulator consumer handles. The same window exists if remove calls try_charger_enable(cm, false) after the put loop, or if userspace hits externally_control during probe before regulator_get completes. Corrupting the freed object can panic the kernel or, with further memory-corruption technique, elevate to root. No public exploit, named APT, or ransomware campaign is reported for this CVE.

How to fix it

Apply the vendor or distribution kernel update that includes the charger-manager ordering fix: acquire regulators (charger_manager_get_regulators / regulator_get only) before power_supply_register so sysfs is not live before handles exist; on teardown, run power_supply_unregister() and try_charger_enable(cm, false) before the regulator_put() loop on both remove and err_reg_extcon. Exact package versions were not supplied with this advisory—use the latest stable kernel from your distro or SoC vendor that contains this change, then reboot into the patched kernel. Until patched, restrict unprivileged write access to power_supply sysfs, prevent untrusted users from unbinding the driver or unloading charger-manager, and treat the remaining extcon-notifier UAF on the same handles as unmitigated (it needs separate synchronization).

How to confirm the fix worked

Confirm the running kernel includes the reordered probe/remove paths (regulators obtained before power_supply_register; unregister and try_charger_enable(false) before regulator_put). Verify whether charger-manager is loaded (lsmod / sysfs) and whether any power_supply device exposes externally_control. After patching, reboot, reload or rebind the driver, and confirm probe succeeds without racing sysfs against missing regulators. On unpatched kernels, treat presence of charger-manager plus untrusted local sysfs writers as exposed. Review dmesg/journal for charger-manager probe, remove, and regulator errors around driver bind/unbind.

Typical attack path

1. Obtain local low-privileged code execution or a shell on a Linux host that uses the charger-manager driver
2. Locate charger-manager power_supply sysfs, including the externally_control attribute
3. Race driver teardown (unbind, module unload, or probe error) or early probe against writes to that sysfs attribute
4. Cause try_charger_enable() or disable-on-remove to use regulator consumer handles after regulator_put() (or before regulator_get)
5. Convert the resulting kernel use-after-free into a denial of service (oops/panic) or local privilege escalation

How to detect it

There is no public exploit, named actor, or ransomware use, so hunt for kernel failure artifacts rather than malware hashes. Collect dmesg, journalctl -k, crash dumps, and kdump/vmcore from around driver bind/unbind and module unload. Search oops, panic, and KASAN/KFENCE reports for charger_manager, charger_externally_control_store, try_charger_enable, charger_manager_remove, charger_manager_register_extcon, and regulator_put/regulator consumer traces. Correlate with userspace writes to power_supply externally_control, uevents for power_supply unregister, and module remove of charger-manager. A KASAN use-after-free or paging request in those frames during unbind is the strongest sign the race was hit; absence of such logs does not prove non-exploitation of a successful silent UAF.

• charger_externally_control_store
• try_charger_enable
• charger_manager_remove
• charger_manager_register_extcon
• charger_manager_get_regulators
• KASAN: use-after-free
• externally_control
• /sys/class/power_supply/
• charger-manager
• power_supply_unregister
• regulator_put

What your security team should do

• Prioritize kernel updates for embedded, IoT, industrial, and mobile images that ship charger-manager; reboot into the patched kernel
• Inventory hosts and images where the charger-manager module or built-in driver is present and where power_supply sysfs is writable by non-root users or containers
• Until patched, lock down writes to power_supply sysfs (especially externally_control) and block unprivileged driver unbind/module unload
• Do not assume this patch closes all charger-manager UAFs; track follow-on fixes for the extcon-notifier path on the same regulator handles
• Watch for kernel oops/KASAN reports citing charger-manager even though EPSS is low, KEV is false, and no in-the-wild exploit is known
• Reassess after vendor backport publication because no canonical fixed version list was provided with this record