CVE-2026-89472
nicheUse-after-free in Linux kernel charger-manager via sysfs externally_control race
The Linux kernel's charger-manager power-supply driver contains a use-after-free in its probe and teardown ordering: charger regulators are freed with regulator_put() before the power_supply sysfs entries are unregistered, so a concurrent write to a charger's externally_control sysfs attribute — or the driver's own try_charger_enable() call during removal — dereferences already-freed regulator consumer handles. A locally logged-in user with low privileges can trigger it by writing to the externally_control attribute in the window between regulator release and sysfs teardown, for example during module unload, driver unbind, or a failed probe. Successful exploitation yields a kernel use-after-free with high confidentiality, integrity, and availability impact (CVSS 3.1: 7.8, local vector, low privileges), plausibly enabling privilege escalation, memory corruption, or a system crash. Affected systems are Linux devices whose kernels enable the charger-manager driver and instantiate a charger-manager device — typically battery-powered embedded/ARM platforms such as Exynos-based boards — rather than standard servers, desktops, or cloud images. The flaw was found by an in-house static analysis tool; no public PoC exists and no exploitation in the wild is known, and note that a related extcon-notifier-driven race on the same regulator handles is explicitly left unfixed by this patch.
What to do: Update to a kernel release that carries the charger-manager ordering fix as soon as your distribution or vendor ships it (stable trees backporting the commit). Until then, on devices running charger-manager, restrict local unprivileged accounts and sysfs write access to the charger's externally_control attribute, and avoid unbinding or unloading the charger-manager driver on production systems. Monitor for a follow-up patch, since the related extcon-notifier-driven dereference of the same regulator handles is explicitly not addressed by this fix.
| Linux kernel (drivers/power/supply/charger-manager) | — |
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: charger-manager: register regulators before exposing sysfs charger_manager_remove() and the err_reg_extcon probe error path free each charger regulator with regulator_put() before tearing down the power_supply sysfs entries (power_supply_unregister()). charger_manager_remove() also calls try_charger_enable(cm, false) after the regulator_put() loop. A concurrent write to a charger's externally_control sysfs attribute that lands between regulator_put() and power_supply_unregister() can run charger_externally_control_store() and call try_charger_enable(), which, when charging is enabled, dereferences the already-freed consumer handle. When charging is enabled, try_charger_enable(cm, false) in .remove() also dereferences the freed handles directly. Both leave use-after-free windows. Symmetrically, probe registers the sysfs entries (power_supply_register) before acquiring the regulators (regulator_get, inside charger_manager_register_extcon), so userspace can reach externally_control before the regulators are available. Split charger_manager_register_extcon() on the sync/async boundary: charger_manager_get_regulators() (regulator_get only, no async producer) now runs before power_supply_register() so sysfs is not live before regulators are available, and charger_manager_register_extcon() keeps only the extcon notifier/work setup, still after power_supply_register() so a power_supply_register() failure cannot reach extcon setup. This keeps the sysfs setup/teardown ordering symmetric without introducing an asynchronous producer on the earlier probe-error path. Move power_supply_unregister() and try_charger_enable(cm, false) ahead of the regulator_put() loop on both teardown paths, and adjust err_reg_extcon (power_supply_unregister() then fall through err_regulator for regulator_put(); get_regulators self-rolls back on its own failure). This does not address the separate extcon-notifier-driven deref of the same handles, which needs its own synchronization design. Found by an in-house static analysis tool.
- Vector
- CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
In the news0 stories
No ingested article mentions this CVE yet.