CVE-2026-45916

power: supply: sbs-battery: Fix use-after-free in power_supply_changed()

HIGH
7.8
CVSS Score
Published: May 27, 2026 at 12:17 PM UTC
Updated: June 27, 2026 at 11:41 AM UTC
1 product affected across 1 vendorLinux Kernel

Using Linux by Linux?

Get instant alerts when new vulnerabilities affect Linux - before attackers find them.

Real-time alertsTrack your software stackFree plan available
Severity
HIGH7.8
Exploit prediction
EPSS 0.2%

Description

In the Linux kernel, the following vulnerability has been resolved: power: supply: sbs-battery: Fix use-after-free in power_supply_changed() Using the `devm_` variant for requesting IRQ _before_ the `devm_` variant for allocating/registering the `power_supply` handle, means that the `power_supply` handle will be deallocated/unregistered _before_ the interrupt handler (since `devm_` naturally deallocates in reverse allocation order). This means that during removal, there is a race condition where an interrupt can fire just _after_ the `power_supply` handle has been freed, *but* just _before_ the corresponding unregistration of the IRQ handler has run. This will lead to the IRQ handler calling `power_supply_changed()` with a freed `power_supply` handle. Which usually crashes the system or otherwise silently corrupts the memory... Note that there is a similar situation which can also happen during `probe()`; the possibility of an interrupt firing _before_ registering the `power_supply` handle. This would then lead to the nasty situation of using the `power_supply` handle *uninitialized* in `power_supply_changed()`. Fix this racy use-after-free by making sure the IRQ is requested _after_ the registration of the `power_supply` handle. Keep the old behavior of just printing a warning in case of any failures during the IRQ request and finishing the probe successfully.

Affected

Our own answer: ranges merged, affected separated from platform-only, with confidence and review flags.

4.9 ≤ v < 5.10.2524.9 ≤ v < 5.15.2024.9 ≤ v < 6.1.1654.9 ≤ v < 6.12.754.9 ≤ v < 6.18.144.9 ≤ v < 6.19.44.9 ≤ v < 6.6.1284.9 ≤ v < 7.05.11 ≤ v < 5.15.2025.16 ≤ v < 6.1.1656.13 ≤ v < 6.18.146.19 ≤ v < 6.19.46.2 ≤ v < 6.6.1286.7 ≤ v < 6.12.754.9d2cec82c28802da31596b395ad292cb8f132fd63
Vendor states this is fixed in 14d4dee5d8fb361bfff275832087254beab66d72 (fixed)
Vendor states this is fixed in 2078830c32d1e49ac942c6f8c21f35c806ae5e94 (fixed)
Vendor states this is fixed in 8010b745b436c3e1ca5dd960aa29fa3e0f6d8841 (fixed)
Vendor states this is fixed in 82d3eb97a976c9d56bb92b241397610e57a9c629 (fixed)
Vendor states this is fixed in 861dda7a9074c0ff67788928165ae39d7f647491 (fixed)
Vendor states this is fixed in 8d59cf3887fbabacef53bfba473e33e8a8d9d07b (fixed)
Vendor states this is fixed in ca7dd71773e4e050b0fb98768b7eae60f8d1f38b (fixed)
Vendor states this is fixed in f1f472b14ad56104ba228b8fbec60d5b21829913 (fixed)
Vendor states this is fixed in 4.9 (unaffected)
Vendor states this is fixed in 5.10.252 (unaffected)
Vendor states this is fixed in 5.15.202 (unaffected)
Vendor states this is fixed in 6.1.165 (unaffected)
Vendor states this is fixed in 6.12.75 (unaffected)
Vendor states this is fixed in 6.18.14 (unaffected)
Vendor states this is fixed in 6.19.4 (unaffected)
Vendor states this is fixed in 6.6.128 (unaffected)
Vendor states this is fixed in 7.0 (unaffected)

CVSS

Attack Vector
LOCAL
Complexity
LOW
Privileges
LOW
User Interaction
NONE
Scope
UNCHANGED
Confidentiality
HIGH
Integrity
HIGH
Availability
HIGH
Vector?

Quick Info

StatusUNDERGOING ANALYSIS
CWE
CWE-416

Get alerted

Stop reading CVE feeds looking for your own stack

Track the products you run and VulnTracker tells you when a new CVE affects them — with what is known about fixing it, and nothing about the rest.

Free plan, no card