CVE-2026-89472
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.
Read full descriptionShow less
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.
CVSS
- Version: 3.1
- Vector: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
- Base score: 7.8
Exploitation probability (EPSS)
- Probability of exploitation in the next 30 days: 0.16%
- Percentile among all scored CVEs: 5
- Score date: 10/6/2026
EPSS (Exploit Prediction Scoring System, FIRST) estimates how likely a vulnerability is to be exploited in the wild within 30 days. It complements CVSS (impact) and CISA KEV (confirmed exploitation).
🎯 ATT&CK techniques
How this vulnerability is exploited and what the attacker gains, in MITRE ATT&CK terms.
- Exploitation
T1068Exploitation for Privilege Escalationprivilege escalation85 % - Primary impact
T1499.004Application or System Exploitationimpact75 % - Secondary impact
T1565.001Stored Data Manipulationimpact60 %
Vulnerabilidad de use-after-free en kernel Linux con acceso local (AV:L/PR:L) que permite a un usuario local provocar denegación de servicio o corrupción de memoria mediante escritura en sysfs durante ventana de race condition.
Inferred by our analysis agent from the official description, CVSS vector and CWE, and checked by a supervisor. May contain errors.
🛡️ ATT&CK mitigations that cover these techniques
Affected technologies (1)
⚠ AI-inferred from the description — NVD hasn't analyzed this CVE yet, these aren't verified CPEs.
References
Raw JSON (NVD)
Show
{
"id": "CVE-2026-89472",
"cveTags": [],
"metrics": {
"cvssMetricV31": [
{
"type": "Secondary",
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"cvssData": {
"scope": "UNCHANGED",
"version": "3.1",
"baseScore": 7.8,
"attackVector": "LOCAL",
"baseSeverity": "HIGH",
"vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"integrityImpact": "HIGH",
"userInteraction": "NONE",
"attackComplexity": "LOW",
"availabilityImpact": "HIGH",
"privilegesRequired": "LOW",
"confidentialityImpact": "HIGH"
},
"impactScore": 5.9,
"exploitabilityScore": 1.8
}
]
},
"affected": [
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"affectedData": [
{
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"product": "Linux",
"versions": [
{
"status": "affected",
"version": "3950c7865cd7c963982a2c94457182b96732f4c9",
"lessThan": "af3ce383ba0d0d48957a22ac7058ff5698775898",
"versionType": "git"
},
{
"status": "affected",
"version": "3950c7865cd7c963982a2c94457182b96732f4c9",
"lessThan": "86e4fa65368f3bbb506dddba8c9eedc75bd603b2",
"versionType": "git"
},
{
"status": "affected",
"version": "3950c7865cd7c963982a2c94457182b96732f4c9",
"lessThan": "6d532582ff3c420598f02945b13184c738cc1581",
"versionType": "git"
},
{
"status": "affected",
"version": "3950c7865cd7c963982a2c94457182b96732f4c9",
"lessThan": "c57cb36f76eb7ced45f57af1a890d8f3a6d76342",
"versionType": "git"
}
],
"programFiles": [
"drivers/power/supply/charger-manager.c"
],
"defaultStatus": "unaffected"
},
{
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"product": "Linux",
"versions": [
{
"status": "affected",
"version": "3.7"
},
{
"status": "unaffected",
"version": "0",
"lessThan": "3.7",
"versionType": "semver"
},
{
"status": "unaffected",
"version": "6.12.109",
"versionType": "semver",
"lessThanOrEqual": "6.12.*"
},
{
"status": "unaffected",
"version": "6.18.50",
"versionType": "semver",
"lessThanOrEqual": "6.18.*"
},
{
"status": "unaffected",
"version": "7.2.4",
"versionType": "semver",
"lessThanOrEqual": "7.2.*"
},
{
"status": "unaffected",
"version": "7.3-rc1",
"versionType": "original_commit_for_fix",
"lessThanOrEqual": "*"
}
],
"programFiles": [
"drivers/power/supply/charger-manager.c"
],
"defaultStatus": "affected"
}
]
}
],
"published": "2026-09-11T20:19:28.393",
"references": [
{
"url": "https://git.kernel.org/stable/c/6d532582ff3c420598f02945b13184c738cc1581",
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
},
{
"url": "https://git.kernel.org/stable/c/86e4fa65368f3bbb506dddba8c9eedc75bd603b2",
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
},
{
"url": "https://git.kernel.org/stable/c/af3ce383ba0d0d48957a22ac7058ff5698775898",
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
},
{
"url": "https://git.kernel.org/stable/c/c57cb36f76eb7ced45f57af1a890d8f3a6d76342",
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
}
],
"vulnStatus": "Received",
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\npower: supply: charger-manager: register regulators before exposing sysfs\n\ncharger_manager_remove() and the err_reg_extcon probe error path free each\ncharger regulator with regulator_put() before tearing down the power_supply\nsysfs entries (power_supply_unregister()). charger_manager_remove() also\ncalls try_charger_enable(cm, false) after the regulator_put() loop. A\nconcurrent write to a charger's externally_control sysfs attribute that\nlands between regulator_put() and power_supply_unregister() can run\ncharger_externally_control_store() and call try_charger_enable(), which,\nwhen charging is enabled, dereferences the already-freed consumer handle.\nWhen charging is enabled, try_charger_enable(cm, false) in .remove() also\ndereferences the freed handles directly. Both leave use-after-free windows.\nSymmetrically, probe registers the sysfs entries (power_supply_register)\nbefore acquiring the regulators (regulator_get, inside\ncharger_manager_register_extcon), so userspace can reach externally_control\nbefore the regulators are available.\n\nSplit charger_manager_register_extcon() on the sync/async boundary:\ncharger_manager_get_regulators() (regulator_get only, no async producer)\nnow runs before power_supply_register() so sysfs is not live before\nregulators are available, and charger_manager_register_extcon() keeps only\nthe extcon notifier/work setup, still after power_supply_register() so a\npower_supply_register() failure cannot reach extcon setup. This keeps the\nsysfs setup/teardown ordering symmetric without introducing an asynchronous\nproducer on the earlier probe-error path.\n\nMove power_supply_unregister() and try_charger_enable(cm, false) ahead of\nthe regulator_put() loop on both teardown paths, and adjust err_reg_extcon\n(power_supply_unregister() then fall through err_regulator for\nregulator_put(); get_regulators self-rolls back on its own failure).\n\nThis does not address the separate extcon-notifier-driven deref of the same\nhandles, which needs its own synchronization design.\n\nFound by an in-house static analysis tool."
}
],
"lastModified": "2026-09-13T07:17:10.520",
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
}