CVE-2026-45938

What it actually does

This is a Linux kernel use-after-free race in the pm8916_lbc power supply driver. The driver requested an interrupt using device-managed cleanup before allocating/registering the associated power_supply object. Because device-managed resources are released in reverse order, device removal can unregister/free the power_supply object before the IRQ handler is removed. If an interrupt fires in that window, the handler can call power_supply_changed() with a freed pointer, causing kernel memory corruption or a kernel crash. A related probe-time race may allow the IRQ handler to use an uninitialized power_supply handle if an interrupt fires before registration completes. The CVSS vector indicates local, low-complexity exploitation requiring low privileges and no user interaction, with potential impact to confidentiality, integrity, and availability if the memory corruption is controllable.

Why it matters to the business

Systems using affected Linux kernels with the vulnerable pm8916_lbc power supply driver may be exposed to local denial of service and possible privilege-escalation risk through kernel memory corruption. The most likely operational consequence is an unexpected crash or reboot on affected hardware, which can disrupt embedded, mobile, IoT, appliance, or edge workloads using this Qualcomm PM8916 battery/charger component. Exploitation is currently assessed as low likelihood based on low EPSS, no known public exploit maturity, and no CISA KEV listing, but kernel memory corruption should still be treated seriously where the driver is present and untrusted local users or workloads exist.

How an attack unfolds

An attacker first needs local code execution or the ability to interact with the affected device in a way that can influence driver bind/unbind, probe/removal, suspend/resume, power-state transitions, or interrupt timing for the pm8916_lbc power supply hardware. The attacker then attempts to trigger the race window in which the power_supply object has been freed or not yet fully initialized while the IRQ handler can still run. If the interrupt fires during that window, the handler invokes power_supply_changed() on an invalid pointer. In the simplest case, this causes a kernel oops, panic, reboot, or device instability. With precise heap grooming and repeatability on a vulnerable platform, the same use-after-free condition may be investigated for broader kernel memory corruption effects, potentially affecting privilege boundaries. Practical exploitation is hardware- and configuration-dependent because the vulnerable path depends on the pm8916_lbc driver and interrupt behavior.

How to fix it

Upgrade to a Linux kernel version that includes the upstream fix for the pm8916_lbc driver. The fix changes initialization/cleanup ordering so the IRQ is requested only after the power_supply handle is registered, preventing the IRQ handler from using a freed or uninitialized handle. If a vendor distribution, Android-derived kernel, embedded BSP, or appliance firmware is used, apply the vendor-provided kernel or firmware update containing this patch rather than relying only on upstream version labels. Where immediate patching is not possible, reduce exposure by disabling or blacklisting the pm8916_lbc driver if the hardware and business function do not require it, restricting local shell/container access on affected systems, limiting privileges that allow driver bind/unbind or module loading/unloading, and avoiding untrusted workloads on affected devices.

How to confirm the fix worked

Confirm the running kernel includes the pm8916_lbc fix from the relevant upstream or vendor branch. Validate vendor advisories, changelogs, or source patches for the driver ordering change in drivers/power/supply/pm8916_lbc.c. On systems where source or build metadata is available, check that IRQ registration occurs after successful power_supply registration and that teardown ordering cannot leave an active IRQ handler referencing a freed power_supply object. At runtime, determine whether the vulnerable driver is present or loaded by checking kernel configuration, loaded modules, sysfs driver bindings, and dmesg output for pm8916_lbc or related power supply registration messages. After patching, exercise supported power, suspend/resume, driver bind/unbind, and device removal scenarios in a test environment and verify there are no kernel oops, use-after-free reports, KASAN warnings, or power_supply_changed-related crashes.

Typical attack path

1. Obtain local access to an affected Linux system or workload with sufficient ability to exercise the vulnerable power supply driver path.
2. Confirm the system loads or can load the pm8916_lbc power supply driver for compatible PM8916/related hardware.
3. Trigger device probe/removal, driver bind/unbind, power transitions, or related events that create interrupt activity around driver registration or teardown.
4. Attempt to cause an interrupt after the power_supply handle has been freed or before it has been initialized.
5. Cause power_supply_changed() to operate on an invalid pointer, resulting in kernel crash, memory corruption, or potentially more severe local compromise depending on exploitability.

How to detect it

Look for evidence of attempted or accidental triggering in kernel logs, persistent journal entries, crash dumps, and monitoring alerts. Relevant sources include dmesg, /var/log/kern.log, /var/log/messages, journalctl -k, pstore/ramoops records, kdump/vmcore analysis, hypervisor or device watchdog reset logs, and vendor appliance crash logs. Search for kernel oops, panic, KASAN, UBSAN, general protection fault, NULL pointer dereference, slab-use-after-free, or page fault messages with stack traces referencing pm8916_lbc, power_supply_changed, power_supply_unregister, devm-managed IRQ teardown, request_threaded_irq, or IRQ handlers associated with the charger/power supply driver. Also review audit logs and shell history for suspicious local activity around module loading/unloading, sysfs driver bind/unbind operations, device unbind/remove actions, or repeated suspend/resume and reboot cycles. Because no public exploit indicators or threat actors are currently reported, detection should focus on behavioral artifacts and crash forensics rather than network IOCs.

• pm8916_lbc
• power_supply_changed
• power_supply_unregister
• drivers/power/supply/pm8916_lbc.c
• KASAN: use-after-free
• BUG: KASAN: slab-use-after-free
• BUG: unable to handle kernel paging request
• general protection fault
• kernel NULL pointer dereference
• Oops:
• Kernel panic - not syncing
• request_threaded_irq
• free_irq
• /sys/bus/platform/drivers/pm8916_lbc/unbind
• /sys/bus/platform/drivers/pm8916_lbc/bind
• /sys/class/power_supply
• pstore
• ramoops
• vmcore

What your security team should do

• Inventory Linux systems, embedded devices, mobile/IoT platforms, and appliances that use kernels containing the pm8916_lbc power supply driver, prioritizing hardware based on Qualcomm PM8916 or vendor BSPs.
• Patch affected systems through the OS, firmware, or appliance vendor as updates become available; prioritize devices where local users, containers, third-party apps, or physical-access users can exercise power/driver behavior.
• If patching is delayed, disable or blacklist the pm8916_lbc driver where it is not required and enforce least privilege for module loading, device management, debugfs/sysfs access, and local shell access.
• Monitor affected fleets for kernel oops, panic, KASAN, or use-after-free messages involving pm8916_lbc, power_supply_changed(), IRQ handling, or driver removal/probe paths.
• Treat unexplained crashes on affected hardware as potentially security-relevant until kernel logs and crash dumps are reviewed.
• Because this is not in CISA KEV, has no reported ransomware use, and has low EPSS at this time, prioritize it behind actively exploited remote vulnerabilities but do not defer patching on multi-user or untrusted-workload systems.