GHSA-P55C-54P6-956P
Vulnerability from github – Published: 2026-09-11 21:31 – Updated: 2026-09-14 15:32In the Linux kernel, the following vulnerability has been resolved:
power: supply: rt9455: quiesce delayed work before teardown
The threaded IRQ handler can queue pwr_rdy_work, max_charging_time_work and batt_presence_work. pwr_rdy_work and batt_presence_work can also queue max_charging_time_work, while batt_presence_work can requeue itself.
rt9455_remove() cancels max_charging_time_work before batt_presence_work. The latter can therefore queue max_charging_time_work after it has already been cancelled:
rt9455_remove() workqueue cancel pwr_rdy_work cancel max_charging_time_work batt_presence_work queues max_charging_time_work cancel batt_presence_work return devres frees rt9455_info max_charging_time_work dereferences rt9455_info
The IRQ also remains registered until devres cleanup and can queue more work after any of the cancellation calls. If rt9455_hw_init() fails after the IRQ has been requested, probe returns without cancelling work that may already have been queued. A pending callback can then access rt9455_info after it has been freed.
Register rt9455_cancel_all_delayed_works() through devm_add_action_or_reset() right after devm_power_supply_register(). devres invokes the action in reverse registration order, after the managed IRQ has been freed and before rt9455_info is released, so the delayed works are drained in both rt9455_remove() and the probe error path. Cancel pwr_rdy_work and batt_presence_work before max_charging_time_work because both can queue the latter.
This issue was found by an in-house static analysis tool.
{
"affected": [],
"aliases": [
"CVE-2026-89465"
],
"database_specific": {
"cwe_ids": [],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-09-11T20:19:27Z",
"severity": "HIGH"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\npower: supply: rt9455: quiesce delayed work before teardown\n\nThe threaded IRQ handler can queue pwr_rdy_work,\nmax_charging_time_work and batt_presence_work. pwr_rdy_work and\nbatt_presence_work can also queue max_charging_time_work, while\nbatt_presence_work can requeue itself.\n\nrt9455_remove() cancels max_charging_time_work before\nbatt_presence_work. The latter can therefore queue\nmax_charging_time_work after it has already been cancelled:\n\n rt9455_remove() workqueue\n cancel pwr_rdy_work\n cancel max_charging_time_work\n batt_presence_work queues\n max_charging_time_work\n cancel batt_presence_work\n return\n devres frees rt9455_info\n max_charging_time_work dereferences\n rt9455_info\n\nThe IRQ also remains registered until devres cleanup and can queue more\nwork after any of the cancellation calls. If rt9455_hw_init() fails\nafter the IRQ has been requested, probe returns without cancelling work\nthat may already have been queued. A pending callback can then access\nrt9455_info after it has been freed.\n\nRegister rt9455_cancel_all_delayed_works() through\ndevm_add_action_or_reset() right after devm_power_supply_register().\ndevres invokes the action in reverse registration order, after the\nmanaged IRQ has been freed and before rt9455_info is released, so the\ndelayed works are drained in both rt9455_remove() and the probe error\npath. Cancel pwr_rdy_work and batt_presence_work before\nmax_charging_time_work because both can queue the latter.\n\nThis issue was found by an in-house static analysis tool.",
"id": "GHSA-p55c-54p6-956p",
"modified": "2026-09-14T15:32:24Z",
"published": "2026-09-11T21:31:27Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-89465"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1b9978433c61a9b46e48832a1ebceee1cf5c9eb4"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3e7a1ebc32fad5a558254a478efd401c17a24381"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/442c60c08ec23ac45da0a58877cab05e0a58f4ea"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/7323e562f6961e4b7bce3225cde4ecbc78260deb"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/df67c7a2fff8414aa766b8cd5ffe11ec1ca27d02"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.