ghsa-x38q-rf72-5pjg
Vulnerability from github
In the Linux kernel, the following vulnerability has been resolved:
power: supply: bq25890: Fix external_power_changed race
bq25890_charger_external_power_changed() dereferences bq->charger, which gets sets in bq25890_power_supply_init() like this:
bq->charger = devm_power_supply_register(bq->dev, &bq->desc, &psy_cfg);
As soon as devm_power_supply_register() has called device_add() the external_power_changed callback can get called. So there is a window where bq25890_charger_external_power_changed() may get called while bq->charger has not been set yet leading to a NULL pointer dereference.
This race hits during boot sometimes on a Lenovo Yoga Book 1 yb1-x90f when the cht_wcove_pwrsrc (extcon) power_supply is done with detecting the connected charger-type which happens to exactly hit the small window:
BUG: kernel NULL pointer dereference, address: 0000000000000018 RIP: 0010:__power_supply_is_supplied_by+0xb/0xb0 Call Trace: __power_supply_get_supplier_property+0x19/0x50 class_for_each_device+0xb1/0xe0 power_supply_get_property_from_supplier+0x2e/0x50 bq25890_charger_external_power_changed+0x38/0x1b0 [bq25890_charger] __power_supply_changed_work+0x30/0x40 class_for_each_device+0xb1/0xe0 power_supply_changed_work+0x5f/0xe0
Fixing this is easy. The external_power_changed callback gets passed the power_supply which will eventually get stored in bq->charger, so bq25890_charger_external_power_changed() can simply directly use the passed in psy argument which is always valid.
{
"affected": [],
"aliases": [
"CVE-2023-53166"
],
"database_specific": {
"cwe_ids": [],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-09-15T14:15:38Z",
"severity": null
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\npower: supply: bq25890: Fix external_power_changed race\n\nbq25890_charger_external_power_changed() dereferences bq-\u003echarger,\nwhich gets sets in bq25890_power_supply_init() like this:\n\n bq-\u003echarger = devm_power_supply_register(bq-\u003edev, \u0026bq-\u003edesc, \u0026psy_cfg);\n\nAs soon as devm_power_supply_register() has called device_add()\nthe external_power_changed callback can get called. So there is a window\nwhere bq25890_charger_external_power_changed() may get called while\nbq-\u003echarger has not been set yet leading to a NULL pointer dereference.\n\nThis race hits during boot sometimes on a Lenovo Yoga Book 1 yb1-x90f\nwhen the cht_wcove_pwrsrc (extcon) power_supply is done with detecting\nthe connected charger-type which happens to exactly hit the small window:\n\n BUG: kernel NULL pointer dereference, address: 0000000000000018\n \u003csnip\u003e\n RIP: 0010:__power_supply_is_supplied_by+0xb/0xb0\n \u003csnip\u003e\n Call Trace:\n \u003cTASK\u003e\n __power_supply_get_supplier_property+0x19/0x50\n class_for_each_device+0xb1/0xe0\n power_supply_get_property_from_supplier+0x2e/0x50\n bq25890_charger_external_power_changed+0x38/0x1b0 [bq25890_charger]\n __power_supply_changed_work+0x30/0x40\n class_for_each_device+0xb1/0xe0\n power_supply_changed_work+0x5f/0xe0\n \u003csnip\u003e\n\nFixing this is easy. The external_power_changed callback gets passed\nthe power_supply which will eventually get stored in bq-\u003echarger,\nso bq25890_charger_external_power_changed() can simply directly use\nthe passed in psy argument which is always valid.",
"id": "GHSA-x38q-rf72-5pjg",
"modified": "2025-09-15T15:31:23Z",
"published": "2025-09-15T15:31:23Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53166"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/029a443b9b6424170f00f6dd5b7682e682cce92e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/72c28207c19c2c46fab8ae994aff25e197fb2949"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9d20fa1982c35697f3f8c4ae0f12791691ae5958"
}
],
"schema_version": "1.4.0",
"severity": []
}
Sightings
| Author | Source | Type | Date |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or seen somewhere by the user.
- Confirmed: The vulnerability is confirmed from an analyst perspective.
- Exploited: This vulnerability was exploited and seen by the user reporting the sighting.
- Patched: This vulnerability was successfully patched by the user reporting the sighting.
- Not exploited: This vulnerability was not exploited or seen by the user reporting the sighting.
- Not confirmed: The user expresses doubt about the veracity of the vulnerability.
- Not patched: This vulnerability was not successfully patched by the user reporting the sighting.