CVE-2026-45902

What it actually does

This is a Linux kernel use-after-free race in the bq256xx power-supply driver. The driver requests an interrupt using device-managed cleanup before registering the associated power_supply object, so teardown happens in the wrong order: the power_supply object can be freed while the IRQ handler is still registered. If an interrupt fires during device removal, or during an initialization window before the object is fully registered, the IRQ handler can call power_supply_changed() with a freed or uninitialized pointer. In practical terms this can cause kernel memory corruption, a kernel crash, or, under favorable conditions, local privilege escalation through controlled use-after-free exploitation. The issue is local attack surface and depends on systems that include and use the affected bq256xx charger/power-supply driver.

Why it matters to the business

Affected Linux systems using the bq256xx power-supply driver may be vulnerable to local denial of service and potentially full system compromise by a user or process with local access. The most likely operational impact is unexpected kernel panic, reboot, or device instability on laptops, embedded devices, mobile-derived platforms, IoT devices, and other systems using the affected charging hardware. Because the CVSS score is high but EPSS is currently very low, there is no public exploit maturity reported, and the issue is not listed in CISA KEV, broad opportunistic exploitation is less likely; however, organizations with multi-user Linux systems or exposed local execution paths should still prioritize kernel updates because successful exploitation could grant high-impact confidentiality, integrity, and availability compromise.

How an attack unfolds

An attacker first needs local code execution on a system running an affected Linux kernel with the bq256xx power-supply driver active. The attacker then attempts to create timing conditions around driver probe, device removal, suspend/resume, hardware event generation, or other power-supply state changes that can cause the bq256xx interrupt handler to run while the associated power_supply structure is freed or not yet initialized. When the interrupt handler calls power_supply_changed() with the stale pointer, the kernel may dereference freed memory. A simple exploit path may only crash the kernel, causing denial of service. A more advanced exploit would attempt heap grooming and race timing so the freed memory is reallocated with attacker-influenced data, potentially turning the use-after-free into kernel memory corruption and privilege escalation. Exploitation is hardware- and timing-dependent, and no mature public exploit is currently indicated.

How to fix it

Upgrade to a Linux kernel build that includes the upstream fix for the bq256xx power-supply driver, which changes initialization and cleanup ordering so the IRQ is requested only after the power_supply handle is registered. No exact fixed package versions were provided in the input, so remediation should be based on the Linux distribution or vendor advisory for CVE-2026-45902. Where immediate patching is not possible, reduce exposure by disabling or blacklisting the bq256xx driver if the hardware is not required, removing untrusted local shell/code execution paths, restricting access to driver bind/unbind and power-management interfaces, and applying standard hardening such as kernel lockdown, module signing, least-privilege user access, and rapid reboot recovery for systems where availability is critical. Mitigations should be validated carefully on embedded or battery-powered devices because disabling a charger/power-supply driver can affect charging, battery reporting, or power management.

How to confirm the fix worked

Confirm the running kernel is a vendor-supported version that includes the bq256xx driver fix. Validate through the distribution changelog, kernel package advisory, or source-level confirmation that the IRQ request occurs after power_supply registration in the bq256xx driver. Check whether the affected driver is present or active using kernel configuration, loaded modules, device tree or ACPI bindings, and sysfs power-supply entries. After patching, reboot into the fixed kernel and confirm the old vulnerable kernel is not still the default boot entry. For mitigation validation, confirm the bq256xx module is not loaded or the affected hardware binding is disabled where operationally acceptable. Stability testing should include charger attach/detach, suspend/resume, and driver lifecycle operations on representative hardware to ensure no kernel warnings, panics, or KASAN reports occur.

Typical attack path

1. Obtain local execution on a Linux system that includes the affected bq256xx power-supply driver and relevant charging hardware or driver bindings.
2. Confirm the bq256xx driver is loaded, built into the kernel, or associated with a present power-supply device.
3. Trigger or wait for power-supply events such as charger attach/detach, interrupt-generating status changes, device probe, driver unbind/removal, suspend/resume, or hotplug-like lifecycle transitions.
4. Race the driver lifecycle so an interrupt fires after the power_supply object has been freed or before it has been fully registered.
5. Cause the IRQ handler to call power_supply_changed() using a stale or uninitialized power_supply pointer.
6. Achieve a kernel crash for denial of service, or attempt heap manipulation to convert the use-after-free into local privilege escalation.

How to detect it

Look for evidence of kernel memory corruption or crashes involving the bq256xx power-supply driver. Relevant log sources include kernel ring buffer output, system journal kernel logs, /var/log/kern.log, /var/log/messages, crash dump records, pstore/ramoops, KASAN reports, and EDR telemetry that records kernel panic or oops events. Search for call traces involving bq256xx interrupt handling, power_supply_changed(), use-after-free, invalid pointer dereference, general protection faults, or kernel panics that occur around charger attach/detach, suspend/resume, device probe, driver unbind, module unload, or power-supply state changes. Existing exploitation is difficult to prove from logs alone because the primitive is a kernel race and a failed exploit may look like an ordinary kernel crash. Repeated crashes involving the same driver, suspicious local activity immediately before driver lifecycle events, attempts to write to sysfs driver bind/unbind paths, or unexplained privilege changes after power-supply-related kernel warnings should be investigated. If crash dumps are available, inspect stack traces for bq256xx functions and power_supply_changed, and review slab/KASAN metadata for use-after-free involving struct power_supply or related driver-private objects.

• bq256xx
• power_supply_changed
• use-after-free
• KASAN: use-after-free
• BUG: KASAN
• general protection fault
• Unable to handle kernel NULL pointer dereference
• Unable to handle kernel paging request
• kernel BUG
• Oops:
• Kernel panic
• Call Trace:
• /sys/bus/platform/drivers
• /sys/bus/i2c/drivers
• /sys/class/power_supply
• /sys/kernel/debug
• bind
• unbind
• bq256xx_charger
• bq256xx_irq

What your security team should do

• Identify Linux assets, especially embedded, mobile, IoT, appliance, and battery-powered systems, that run kernels containing the bq256xx power-supply driver.
• Prioritize patching systems where untrusted users, containers, applications, or remote services can obtain local code execution, because the vulnerability requires local access but can have kernel-level impact.
• Track Linux distribution and device-vendor advisories for the fixed kernel package, since exact fixed versions were not provided in the vulnerability metadata.
• If patching is delayed, assess whether the bq256xx driver can be safely disabled or blacklisted on systems that do not require the associated charging hardware.
• Monitor for kernel crashes, KASAN use-after-free reports, and bq256xx or power_supply_changed-related call traces, especially after charger events, suspend/resume, or driver removal.
• Restrict administrative interfaces that can unbind drivers, manipulate power-management state, or load/unload kernel modules to trusted administrators only.
• Ensure affected systems have crash dump collection enabled where feasible so suspected exploitation or instability can be investigated after reboot.
• Because the vulnerability is not currently in CISA KEV and has low EPSS, treat it as high-impact but not currently mass-exploited; patch during the next prioritized kernel maintenance cycle unless local multi-user risk or device criticality warrants emergency action.