CVE-2026-45879

What it actually does

This is a Linux kernel use-after-free race in the bq25980 power-supply driver. Because the interrupt handler can remain active briefly after the power_supply object has been unregistered and freed, a late hardware interrupt during device removal can cause the handler to call power_supply_changed() with a stale pointer. A related race during probe can call the same path before the power_supply handle is fully initialized. The likely result is a kernel crash, but because the flaw is memory corruption in kernel context, successful exploitation could potentially allow local privilege escalation or arbitrary kernel memory corruption on systems where the affected driver and device path are reachable.

Why it matters to the business

Affected Linux systems can become unstable or crash if the vulnerable bq25980 power-supply driver is present and the race is triggered. In environments using Linux on mobile, embedded, edge, appliance, or battery-powered hardware, this can translate into service outages, device reboots, operational disruption, and possible full system compromise if an attacker can turn the kernel memory corruption into privilege escalation. This issue is not currently listed in CISA KEV, is not known to be used in ransomware campaigns, has low EPSS probability, and has no reported public exploit maturity, so remediation should be prioritized highest for systems that actually include or load the bq25980 driver.

How an attack unfolds

An attacker needs local access with enough privilege or device access to influence the affected driver lifecycle or interrupt timing. They identify a system running a vulnerable Linux kernel with the bq25980 charger/power-supply driver present, then attempt to trigger driver probe or removal while causing or waiting for a charger-related interrupt. During the narrow race window, the interrupt handler can run after the power_supply structure has been freed or before it is initialized, causing power_supply_changed() to operate on invalid kernel memory. A basic exploit attempt would likely cause an oops, panic, or reboot. A more advanced exploit would attempt to shape kernel heap state so that the stale pointer references attacker-influenced memory, potentially enabling privilege escalation or broader kernel compromise.

How to fix it

Upgrade to a Linux kernel build from the relevant distribution or vendor that includes the bq25980 power-supply driver fix, which changes initialization and teardown ordering so the IRQ is requested after the power_supply handle is registered. No exact fixed versions were provided in the input, so track the fix through the upstream Linux stable trees and the security advisories for the deployed distribution, appliance, or device vendor. If immediate patching is not possible and the hardware does not require this charger driver, reduce exposure by preventing the bq25980 driver from loading, blacklisting the module where applicable, disabling the affected device in firmware/device tree configuration, or restricting access to driver bind/unbind interfaces under sysfs. Avoid untrusted local code execution on affected systems until patched.

How to confirm the fix worked

Confirm the running kernel package is at or above the vendor-fixed version for this issue, not merely that an updated package is installed. Verify the bq25980 driver source or vendor patch contains the corrected resource ordering: power_supply registration occurs before the IRQ is requested, so managed cleanup unregisters the IRQ before freeing the power_supply object. On live systems, check whether the bq25980 driver is loaded or built into the kernel, and whether matching hardware is present. After remediation, review boot logs and stress-test relevant charger/power events, driver bind/unbind, suspend/resume, and device removal paths where safe; patched systems should not produce KASAN, kernel oops, panic, or power_supply_changed() crashes involving bq25980.

Typical attack path

1. Gain local execution on a Linux system that uses or exposes the affected bq25980 power-supply driver.
2. Confirm the vulnerable kernel/driver is present, loaded, or can be bound to matching hardware.
3. Trigger driver probe, unbind, removal, suspend/resume, or hardware state changes that affect the bq25980 power-supply device.
4. Induce or wait for a charger/power interrupt during the race window around power_supply registration or IRQ teardown.
5. Cause the interrupt handler to call power_supply_changed() with an uninitialized or freed power_supply handle.
6. Achieve a kernel crash or, with more advanced heap manipulation, attempt local privilege escalation through kernel memory corruption.

How to detect it

Look for evidence of attempted or successful triggering in kernel telemetry rather than network logs, because exploitation is local and driver/hardware dependent. Useful sources include dmesg, journald kernel facility logs, /var/log/kern.log, /var/log/messages, pstore/ramoops, crash dumps, kdump/vmcore artifacts, EDR kernel event telemetry, audit logs for sysfs writes, and command histories where available. Search for kernel oops, panic, KASAN, KFENCE, slab corruption, or general-protection-fault messages involving bq25980, power_supply_changed(), power_supply core code, IRQ handling, or driver probe/remove paths. Also review audit or shell telemetry for unusual writes to sysfs driver bind/unbind files or repeated module load/unload activity involving the bq25980 driver. Because no public exploit indicators are known and the race can look like an ordinary kernel crash, correlate suspicious crashes with local user activity, container escapes attempts, hardware-management actions, or repeated attempts to exercise charger/power-state transitions.

• bq25980
• bq25980_charger
• power: supply: bq25980
• power_supply_changed
• drivers/power/supply/bq25980_charger.c
• KASAN: use-after-free
• BUG: KASAN
• use-after-free in power_supply_changed
• general protection fault
• kernel NULL pointer dereference
• kernel BUG at drivers/power/supply
• Unable to handle kernel paging request
• slab-use-after-free
• /sys/bus/i2c/drivers/bq25980
• /sys/bus/platform/drivers/bq25980
• /sys/bus/i2c/drivers/*/unbind
• /sys/bus/platform/drivers/*/unbind

What your security team should do

• Inventory Linux systems, appliances, embedded devices, and battery-powered platforms for kernels that include or load the bq25980 power-supply driver.
• Prioritize patching systems where the bq25980 driver is active, matching hardware is present, or local users/workloads are not fully trusted.
• Apply vendor kernel updates that include the upstream bq25980 use-after-free fix; reboot into the patched kernel and verify the running kernel version.
• Where patching is delayed, disable or blacklist the bq25980 driver if it is not operationally required.
• Restrict write access to sysfs driver bind/unbind and device-management interfaces to trusted administrators only.
• Monitor kernel logs for bq25980, power_supply_changed(), KASAN use-after-free reports, kernel oopses, panics, or suspicious driver unbind activity.
• Treat unexplained kernel crashes involving this driver as potential security events and preserve logs, crash dumps, and kernel versions for forensic review.