CVE-2026-45946

What it actually does

This is a Linux kernel use-after-free race in the AB8500 power-supply driver. The driver registers managed interrupt handlers and the power_supply object in an unsafe order, so during probe failure or device removal an interrupt can fire while the power_supply handle is not yet initialized or has already been freed. The interrupt handler can then call power_supply_changed() on invalid memory, causing a kernel crash or memory corruption. Because exploitation occurs in kernel context, successful abuse could potentially lead to local privilege escalation, information disclosure, integrity compromise, or denial of service, although the issue appears hardware/driver-specific and no public exploit maturity is reported.

Why it matters to the business

Systems using affected Linux kernels with the AB8500 power-supply driver enabled may be vulnerable to local attacks or fault conditions that crash the device or corrupt kernel memory. The most likely operational impact is instability or denial of service on affected embedded/mobile-style Linux systems using this power-management hardware; worst-case impact is local privilege escalation if the memory corruption can be reliably controlled. The issue is not currently listed in CISA KEV, has very low EPSS, and has no reported exploit maturity, so it should be prioritized according to asset exposure and use of the affected driver rather than treated as broadly internet-exploitable.

How an attack unfolds

An attacker first needs local access with enough privileges or capabilities to influence device lifecycle events, driver binding, module loading/unloading, power-supply state changes, suspend/resume, or hardware interrupt timing on a system using the affected AB8500 driver. The attacker then attempts to create a race during driver probe or removal: either an interrupt is delivered before the power_supply structure has been fully registered, or an interrupt is delivered after that structure has been freed but before the IRQ handler has been unregistered. When the IRQ handler runs, it invokes power_supply_changed() using an invalid pointer. In typical failure cases this produces a kernel oops, panic, or device reboot. In a more advanced exploitation scenario, the attacker would try to shape freed kernel memory so the stale pointer references attacker-influenced data, potentially turning the memory corruption into privilege escalation. Given the hardware-specific driver path, low EPSS, non-KEV status, and no known exploit maturity, practical exploitation is likely limited to systems where the AB8500 driver is present and reachable.

How to fix it

Apply a Linux kernel version or vendor kernel update that includes the fix for the AB8500 power-supply driver initialization/removal ordering. The corrected behavior requests/registers the IRQ only after the power_supply handle has been allocated and registered, preventing the interrupt handler from using an uninitialized or freed object. No exact fixed package versions were provided in the input, so use the relevant distribution, device vendor, or upstream stable kernel advisory to identify the fixed build for each maintained kernel branch. If immediate patching is not possible, mitigate by disabling or unloading the AB8500 power-supply driver where it is not required, removing access to driver bind/unbind controls from untrusted users, limiting local shell access, restricting module loading/unloading, and using kernel hardening controls such as lockdown mode, module signing, KASAN/KFENCE in test environments, and panic/reboot monitoring for production resilience.

How to confirm the fix worked

Confirm exposure by checking whether the running kernel includes the affected AB8500 power-supply driver and whether the target hardware actually uses it. Review kernel configuration and loaded modules for AB8500 power-supply support, inspect /sys/bus/platform/drivers and /sys/class/power_supply for AB8500-related devices, and compare the running kernel package against the vendor-fixed release. Confirm remediation by verifying that the installed kernel contains the patch that registers the power_supply handle before requesting the IRQ and that the system has booted into the fixed kernel. In test environments, exercise driver probe/removal, bind/unbind, suspend/resume, and charging-state transitions while monitoring dmesg or journalctl -k for KASAN, use-after-free, NULL pointer dereference, general protection fault, or power_supply_changed() crashes. Production validation should avoid intentionally racing hardware events unless performed under controlled maintenance conditions.

Typical attack path

1. Identify a Linux system running an affected kernel with the AB8500 power-supply driver present and active.
2. Obtain local access to the system with the ability to trigger relevant driver, device, power-management, or interrupt events.
3. Trigger repeated probe, removal, bind/unbind, suspend/resume, charging, or power-supply state transitions to widen the race window.
4. Cause an AB8500-related interrupt to fire while the power_supply object is uninitialized or already freed.
5. Force the IRQ handler to call power_supply_changed() using the invalid power_supply handle.
6. Achieve a kernel crash/denial of service, or attempt more advanced heap manipulation to convert the use-after-free into kernel-level code execution or privilege escalation.

How to detect it

To determine whether exploitation or triggering has already occurred, review kernel logs and crash artifacts rather than network telemetry, because this is a local kernel driver race. Collect dmesg output, journalctl -k logs, rsyslog/kern.log, crash dumps, pstore/ramoops records, kdump vmcores, and hypervisor or watchdog reset records. Look for kernel oops, panic, KASAN/KFENCE reports, slab use-after-free messages, general protection faults, NULL pointer dereferences, or call traces containing power_supply_changed() and AB8500 power-supply driver functions. Correlate crashes with local user activity involving module load/unload, sysfs driver bind/unbind, power-supply device changes, suspend/resume cycles, charger or battery events, and repeated reboots. Absence of these artifacts does not prove non-exploitation, because memory corruption may be silent or logs may be lost during a panic. Network-based IOCs are not expected for this vulnerability.

• BUG: KASAN: use-after-free
• BUG: KFENCE: use-after-free
• use-after-free in power_supply_changed
• power_supply_changed
• drivers/power/supply/ab8500
• ab8500
• Call Trace:
• kernel BUG
• Oops:
• general protection fault
• Unable to handle kernel NULL pointer dereference
• slab-use-after-free
• RIP: power_supply_changed
• pc : power_supply_changed
• /sys/bus/platform/drivers
• /sys/class/power_supply

What your security team should do

• Inventory Linux assets for kernels that include or load the AB8500 power-supply driver, prioritizing embedded, mobile, development, and hardware-lab systems.
• Patch affected systems using the appropriate distribution or device-vendor kernel update as soon as operationally feasible, especially where local users, containers with elevated device access, or untrusted workloads are present.
• If the driver is not needed, disable it in the kernel configuration, blacklist the module if modular, or remove access to the affected hardware path.
• Restrict local administrative capabilities that can trigger driver lifecycle events, including module loading/unloading, sysfs driver bind/unbind, and direct device access.
• Monitor kernel logs for crashes or memory-corruption signatures involving power_supply_changed(), AB8500 power-supply components, IRQ handling, KASAN, or slab use-after-free reports.
• Because the vulnerability is not KEV-listed, not associated with ransomware use, and has low EPSS, prioritize based on confirmed driver presence and business criticality rather than broad perimeter exposure.
• For products or appliances using custom kernels, request confirmation from the vendor that the AB8500 driver fix has been backported to the supported firmware/kernel branch.