power: supply: charger-manager: register regulators before exposing sysfs
Summary
| CVE | CVE-2026-89472 |
| State | PUBLISHED |
| Assigner | Linux |
| Source Priority | CVE Program / NVD first with legacy fallback |
| Published | 2026-09-11 20:19:28 UTC |
| Updated | 2026-09-11 20:19:28 UTC |
| Description | 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. |
Vendor Declared Affected Products
| Source | Vendor | Product | Version | Platforms |
|---|
| CNA |
Linux |
Linux |
affected 3950c7865cd7c963982a2c94457182b96732f4c9 af3ce383ba0d0d48957a22ac7058ff5698775898 git |
Not specified |
| CNA |
Linux |
Linux |
affected 3950c7865cd7c963982a2c94457182b96732f4c9 86e4fa65368f3bbb506dddba8c9eedc75bd603b2 git |
Not specified |
| CNA |
Linux |
Linux |
affected 3950c7865cd7c963982a2c94457182b96732f4c9 6d532582ff3c420598f02945b13184c738cc1581 git |
Not specified |
| CNA |
Linux |
Linux |
affected 3950c7865cd7c963982a2c94457182b96732f4c9 c57cb36f76eb7ced45f57af1a890d8f3a6d76342 git |
Not specified |
| CNA |
Linux |
Linux |
affected 3.7 |
Not specified |
| CNA |
Linux |
Linux |
unaffected 3.7 semver |
Not specified |
| CNA |
Linux |
Linux |
unaffected 6.12.109 6.12.* semver |
Not specified |
| CNA |
Linux |
Linux |
unaffected 6.18.50 6.18.* semver |
Not specified |
| CNA |
Linux |
Linux |
unaffected 7.2.4 7.2.* semver |
Not specified |
| CNA |
Linux |
Linux |
unaffected 7.3-rc1 * original_commit_for_fix |
Not specified |
References
| Reference | Source | Link | Tags |
|---|
| git.kernel.org/stable/c/c57cb36f76eb7ced45f57af1a890d8f3a6d76342 |
416baaa9-dc9f-4396-8d5f-8c081fb06d67 |
git.kernel.org |
|
| git.kernel.org/stable/c/86e4fa65368f3bbb506dddba8c9eedc75bd603b2 |
416baaa9-dc9f-4396-8d5f-8c081fb06d67 |
git.kernel.org |
|
| git.kernel.org/stable/c/6d532582ff3c420598f02945b13184c738cc1581 |
416baaa9-dc9f-4396-8d5f-8c081fb06d67 |
git.kernel.org |
|
| git.kernel.org/stable/c/af3ce383ba0d0d48957a22ac7058ff5698775898 |
416baaa9-dc9f-4396-8d5f-8c081fb06d67 |
git.kernel.org |
|
| CVE Program record |
CVE.ORG |
www.cve.org |
canonical |
| NVD vulnerability detail |
NVD |
nvd.nist.gov |
canonical, analysis |
No vendor comments have been submitted for this CVE.
There are currently no legacy QID mappings associated with this CVE.