CVE-2026-45882

What it actually does

This is a Linux kernel use-after-free and uninitialized-use race in the pm8916_bms_vm power-supply driver. The driver requested its IRQ using devm-managed cleanup before registering the power_supply object, causing teardown to unregister/free the power_supply object before the IRQ handler is removed. If an interrupt fires during that window, the IRQ handler can call power_supply_changed() with a freed pointer. A similar race can occur during probe if an interrupt fires before the power_supply handle is fully registered. The likely result is a kernel crash, but because the flaw is kernel memory corruption, a local attacker with the ability to trigger the affected driver/interrupt path may be able to escalate privileges or corrupt kernel memory depending on platform exposure and exploit reliability.

Why it matters to the business

Affected Linux systems using the vulnerable pm8916_bms_vm power-supply driver may be vulnerable to local denial of service through kernel panic and, in worst cases, local privilege escalation. This is most relevant to devices or embedded Linux platforms using Qualcomm PM8916-related battery-management hardware or kernels that include and load this driver. The CVSS score is high, but the exposure is hardware and configuration dependent, EPSS is currently very low, it is not listed in CISA KEV, and no public exploit maturity is reported, so remediation should be prioritized for exposed device fleets and kernel builds where the driver is enabled or loaded.

How an attack unfolds

An attacker first needs local access to an affected Linux system and a way to interact with or influence the affected power-supply driver lifecycle or interrupt behavior. The attacker attempts to create timing pressure around driver probe or removal, suspend/resume, device rebinding, module unload/reload, or hardware/power events that can generate the battery-management IRQ. If the interrupt fires after the power_supply structure is freed but before the IRQ handler is unregistered, or before the structure is initialized during probe, the handler calls power_supply_changed() with an invalid pointer. In simple cases this causes an immediate kernel oops or panic. A more advanced attacker would try to groom kernel memory so the freed object is replaced with attacker-influenced data, potentially turning the race into controlled memory corruption and local privilege escalation. Practical exploitability depends heavily on whether the driver is present, whether the relevant hardware/IRQ is active, kernel hardening, module permissions, and the attacker’s ability to reliably hit the race window.

How to fix it

Upgrade to a Linux kernel version or vendor kernel package that includes the upstream fix changing the resource-allocation order so the IRQ is requested only after the power_supply handle is registered. No exact fixed package versions were provided in the input, so use the distribution, device vendor, or upstream stable kernel advisory for the applicable fixed release. Where immediate patching is not possible, reduce exposure by disabling or blacklisting the pm8916_bms_vm driver if the hardware is not required, removing unused device-tree bindings for the affected battery-management component, preventing unprivileged users from loading/unloading kernel modules, and limiting access to sysfs/debugfs interfaces that can trigger device bind/unbind or power-management transitions. Embedded and mobile device vendors should rebuild kernels with the corrected driver code and verify that the affected driver is either patched or not included.

How to confirm the fix worked

Confirm remediation by verifying that the running kernel package includes the patch that registers the power_supply handle before requesting the IRQ in the pm8916_bms_vm driver. Check vendor kernel changelogs, source package diffs, or the built kernel source for the corrected ordering in drivers/power/supply/pm8916_bms_vm.c. On deployed systems, confirm the running kernel version matches a vendor-fixed release, then check whether the driver is present or loaded using lsmod, modinfo, /proc/modules, /sys/module, and kernel configuration data such as /boot/config-$(uname -r). If the driver is not required, validate that it is not loaded and cannot be auto-loaded. For QA or lab validation, exercise probe/remove, module reload, suspend/resume, and device bind/unbind paths under KASAN/KFENCE or similar kernel memory debugging and confirm there are no use-after-free reports, kernel oopses, or power_supply_changed() crashes.

Typical attack path

1. Gain local, low-privileged access to a Linux system where the pm8916_bms_vm driver is enabled and relevant hardware or device-tree configuration is present.
2. Determine whether the vulnerable power-supply driver is loaded, built in, or can be bound to a device.
3. Trigger driver lifecycle activity such as probe, remove, module unload/reload, device unbind/rebind, suspend/resume, or related power-management events.
4. Generate or wait for the associated battery-management interrupt during the vulnerable timing window.
5. Cause the IRQ handler to call power_supply_changed() using a freed or uninitialized power_supply handle.
6. Achieve kernel denial of service through panic/oops, or attempt kernel heap grooming to convert the memory corruption into privilege escalation.

How to detect it

Look for evidence of prior exploitation or attempted triggering in kernel logs and crash artifacts. Relevant sources include dmesg, journald kernel messages, /var/log/kern.log, /var/log/messages, pstore/ramoops, kdump/vmcore data, apport/abrt crash reports, and EDR telemetry for module load/unload or sysfs device bind/unbind activity. Search for kernel oopses, panics, KASAN/KFENCE use-after-free reports, general protection faults, NULL/uninitialized pointer reports, or stack traces involving pm8916_bms_vm, power_supply_changed(), IRQ handlers, driver probe/remove, device unbind/rebind, or suspend/resume. Also review audit logs and shell history, where available, for repeated access to /sys/bus/*/drivers/*/bind, /sys/bus/*/drivers/*/unbind, modprobe, insmod, rmmod, or power-management test interfaces shortly before a crash. There are no known network indicators because exploitation is local and hardware/driver dependent. Absence of logs does not prove absence of exploitation, because successful memory corruption may leave only a crash or no durable artifact.

• pm8916_bms_vm
• power_supply_changed
• drivers/power/supply/pm8916_bms_vm.c
• BUG: KASAN: use-after-free
• BUG: KFENCE: use-after-free
• use-after-free in power_supply_changed
• general protection fault
• kernel BUG
• Unable to handle kernel paging request
• Oops:
• Kernel panic
• Call Trace:
• RIP: power_supply_changed
• PC is at power_supply_changed
• /sys/bus/platform/drivers/*/unbind
• /sys/bus/platform/drivers/*/bind
• rmmod pm8916_bms_vm
• modprobe pm8916_bms_vm
• insmod pm8916_bms_vm

What your security team should do

• Inventory Linux kernels and embedded device firmware to identify systems where the pm8916_bms_vm driver is built in, loadable, or active.
• Prioritize patching for devices using Qualcomm PM8916-related battery-management hardware, mobile/embedded fleets, and systems where local users or applications can trigger module or device lifecycle events.
• Apply vendor kernel updates as soon as available; if maintaining a custom kernel, backport the upstream driver fix to drivers/power/supply/pm8916_bms_vm.c.
• If the driver is not needed, disable it in the kernel configuration or blacklist the module and verify it cannot be loaded automatically.
• Restrict kernel module loading/unloading and device bind/unbind operations to trusted administrators only.
• Enable kernel hardening and memory-corruption mitigations where feasible, including KASLR, slab freelist hardening, module signature enforcement, lockdown mode, and panic/oops monitoring.
• Monitor kernel logs for crashes, KASAN reports, or oops traces involving pm8916_bms_vm, power_supply_changed(), or IRQ handling on affected platforms.
• Because the vulnerability is not currently in KEV, has very low EPSS, and has no known public exploit maturity, treat it as configuration-dependent high severity rather than broad internet-exploited risk.