CVE-2026-45885

What it actually does

This is a Linux kernel use-after-free race in the cpcap-battery power supply driver. The driver requests an interrupt using device-managed cleanup before registering the power_supply object, so teardown occurs in the reverse order: the power_supply object can be freed before the IRQ handler is unregistered. If an interrupt fires during device removal, suspend/resume, driver unbind, or related lifecycle transitions, the IRQ handler may call power_supply_changed() with a freed pointer. A related probe-time race can allow the handler to use an uninitialized power_supply handle. The likely outcomes are kernel crash, memory corruption, and potentially local privilege escalation if an attacker can reliably trigger the race and shape kernel memory reuse. The CVSS vector indicates local access with low complexity and low privileges required, no user interaction, and potential high confidentiality, integrity, and availability impact.

Why it matters to the business

Affected Linux systems using hardware that relies on the cpcap-battery driver may be exposed to local kernel compromise or denial of service. In practical terms, a low-privileged local user or compromised local process could potentially crash the device or, with a working exploit, gain kernel-level control. This is especially relevant for embedded, mobile, industrial, or appliance-like Linux deployments where battery/power-supply drivers are enabled and physical or local shell access is possible. The vulnerability is not listed in CISA KEV, is not known to be used in ransomware campaigns, and currently has very low EPSS, so broad internet-scale exploitation is not expected; however, kernel local privilege escalation flaws should still be prioritized on multi-user systems, exposed appliances, and fleets where untrusted code can run.

How an attack unfolds

An attacker first needs local code execution with low privileges on a system running an affected kernel with the cpcap-battery driver present and usable. The attacker then attempts to trigger driver lifecycle transitions, such as device unbind/rebind, module removal if permitted, suspend/resume activity, or other power-supply state changes that cause the driver to unregister while interrupts may still arrive. During the vulnerable race window, an interrupt can invoke the cpcap-battery IRQ handler after the power_supply structure has been freed or before it has been initialized. In the simplest case this causes a kernel oops, panic, or hang. A more advanced attacker would try to repeatedly trigger the race while influencing kernel heap allocations so the freed memory is replaced with attacker-controlled or useful data, potentially turning the memory corruption into kernel privilege escalation. No public exploit maturity is indicated in the provided data, so exploitation should be treated as plausible but not currently widespread.

How to fix it

Upgrade to a Linux kernel version or vendor kernel package that includes the fix for the cpcap-battery driver cleanup/registration ordering, where the IRQ is requested only after the power_supply handle is registered. No exact fixed versions were provided, so use the relevant distribution, device vendor, or upstream stable kernel advisory to identify the corrected package for each supported kernel branch. Where immediate patching is not possible, reduce exposure by disabling or blacklisting the cpcap-battery driver if the hardware does not require it, removing untrusted local shell access, preventing unprivileged users from loading/unloading modules or unbinding devices, restricting debugfs/sysfs access that can trigger device lifecycle changes, and applying kernel hardening features such as lockdown mode, module signing, KASLR, hardened slab options, and panic/oops handling appropriate to the environment. Mitigations should not be considered a full substitute for applying the kernel fix.

How to confirm the fix worked

Confirm exposure by checking whether the running kernel is from a vendor build that contains the cpcap-battery fix and whether the cpcap-battery driver is built in or loaded. Validate remediation by confirming the installed kernel package version matches the vendor-fixed release, rebooting into the fixed kernel, and verifying that older vulnerable kernels are not the active boot default. On source-based or custom kernels, inspect drivers/power/supply/cpcap-battery.c to confirm the power_supply registration occurs before the IRQ request and that cleanup order no longer permits an IRQ handler to run after the power_supply object has been freed. Operationally, monitor dmesg or journal logs during suspend/resume, driver bind/unbind, and battery event testing for absence of kernel oops, KASAN use-after-free reports, or power_supply_changed crashes involving cpcap-battery.

Typical attack path

1. Gain local low-privileged execution on an affected Linux system.
2. Verify that the kernel includes and has loaded or can reach the cpcap-battery power supply driver.
3. Trigger battery/power-supply events and driver lifecycle changes such as unbind/rebind, suspend/resume, or module/device removal where permissions allow.
4. Race an interrupt against driver probe or removal so the IRQ handler references an uninitialized or freed power_supply handle.
5. Cause kernel memory corruption, typically resulting in a crash or denial of service.
6. For advanced exploitation, repeatedly trigger the race while manipulating kernel heap reuse to attempt privilege escalation to kernel/root level.

How to detect it

To assess possible prior exploitation, review kernel logs rather than network telemetry, because this is a local kernel race and does not have a reliable remote signature. Collect dmesg, journald/kern.log, syslog, crash dumps, vmcore data, pstore/ramoops, and EDR telemetry for kernel crashes or memory-safety reports involving cpcap-battery, power_supply_changed(), IRQ handling, driver removal, suspend/resume, or device bind/unbind activity. Look for repeated kernel oops/panic events preceded by local user activity touching /sys/bus, /sys/class/power_supply, module management commands, suspend/resume triggers, or abnormal battery/power events. KASAN, KFENCE, UBSAN, or hardened kernel reports containing use-after-free near power_supply_changed are strong indicators of attempted triggering or accidental exposure. Also review audit logs for low-privileged users invoking modprobe, rmmod, insmod, writing to driver unbind/bind files, or interacting with power management interfaces shortly before a crash. Because successful privilege escalation may leave few unique artifacts, correlate suspicious crashes with new root-level processes, unexpected setuid file changes, kernel module loads, disabled security tooling, or post-crash persistence changes.

• cpcap-battery
• cpcap_battery
• power_supply_changed
• BUG: KASAN: use-after-free
• use-after-free in power_supply_changed
• kernel BUG at drivers/power/supply/cpcap-battery.c
• drivers/power/supply/cpcap-battery.c
• Unable to handle kernel NULL pointer dereference
• general protection fault
• kernel panic
• Oops:
• /sys/class/power_supply
• /sys/bus/platform/drivers/cpcap-battery/unbind
• /sys/bus/platform/drivers/cpcap-battery/bind
• rmmod cpcap_battery
• modprobe cpcap_battery

What your security team should do

• Inventory Linux systems, embedded devices, appliances, and custom kernels that include or load the cpcap-battery driver.
• Prioritize patching systems that allow local users, run third-party workloads, expose shell access, or are physically accessible to untrusted parties.
• Obtain fixed kernel packages from the OS, device, or appliance vendor and schedule reboots so the fixed kernel is actually running.
• If patching is delayed and the driver is unnecessary, disable or blacklist cpcap-battery and verify the module is not loaded.
• Restrict local attack surface by limiting untrusted users, container escape opportunities, module loading, device unbind/rebind permissions, and access to sensitive sysfs/debugfs interfaces.
• Enable and review kernel crash, audit, and centralized log collection for oops, panic, KASAN, and power-supply driver anomalies.
• For custom kernel maintainers, backport the upstream driver ordering fix into all supported kernel branches and run lifecycle stress tests around probe, remove, suspend, resume, and IRQ delivery.