CVE-2026-89467

What it actually does

A use-after-free in the Linux kernel Qualcomm battery-manager driver (qcom_battmgr) allows a workqueue callback to touch the battmgr object after it has been freed. qcom_battmgr_pdr_notify() queues enable_work when the PMIC GLINK service comes up; the worker recovers battmgr via container_of() and issues firmware requests. Because the PMIC GLINK client remains on the client list until its devres release action runs, a protection-domain restart (PDR) notification can still queue work during or after teardown, so a pending or running worker accesses freed kernel memory. Consequences are kernel memory corruption, oops/panic (denial of service), and, in principle, local privilege escalation if the freed object is reclaimed and corrupted before the worker runs. The issue is local, Qualcomm-GLINK-specific, and was found by static analysis rather than in-the-wild abuse.

Why it matters to the business

Impact is concentrated on Qualcomm-based Linux, Android, automotive, and embedded devices that use PMIC GLINK battery management—not typical enterprise servers or cloud hosts. EPSS is very low (~0.002) and flat over 30 days, the CVE is not in CISA KEV, ransomware use is not reported, and exploit maturity is none, so organizational urgency is low-to-moderate and should follow normal vendor kernel maintenance rather than an emergency campaign. Residual risk is unexpected reboots or battery-stack instability on affected SoCs, plus a theoretical local-escalation path if an attacker already has code execution on the device. Patch when OEM/upstream kernels absorb the fix; non-Qualcomm fleets can deprioritize.

How an attack unfolds

There is no public exploit, named threat actor, or KEV activity for this issue. A realistic attacker would already have local access on a Qualcomm Linux/Android device with qcom_battmgr loaded, then try to race device teardown (unbind, remove, or module lifetime end) against PMIC GLINK PDR/service-up notifications that keep queueing enable_work. If the worker runs after battmgr is freed, the kernel use-after-free can crash the system. Turning that race into reliable privilege escalation would additionally require controlling slab reuse of the freed object and surviving without an immediate oops—conditions that are hardware- and timing-specific and currently unproven. Detection should therefore focus on kernel failure artifacts, not network C2.

How to fix it

Apply the upstream Linux kernel fix that registers enable_work as device-managed with devm_work_autocancel() before the PMIC GLINK client is allocated, so teardown drops the client first (no further PDR notifications queue work) and cancels the work before battmgr is freed. Upgrade to a vendor or linux-stable/LTS kernel that includes the commit titled essentially “power: supply: qcom_battmgr: fix use-after-free.” Exact distro/OEM package versions were not supplied; track Android OEM, automotive, and distro kernel advisories for this change. If battery management via this driver is not required, do not load qcom_battmgr. There is no reliable userspace-only mitigation on devices that need this driver.

How to confirm the fix worked

Confirm the running kernel changelog or git history contains the qcom_battmgr use-after-free fix (devm_work_autocancel on enable_work, ordered before PMIC GLINK client allocation). On live systems, identify whether qcom_battmgr is built-in or loaded, and whether PMIC GLINK battery management is in use. After patching, regression-test device unbind/reboot and GLINK service restart paths and verify no new workqueue UAF/KASAN reports or oopses in qcom_battmgr. Unpatched exposure is limited to Qualcomm platforms with this driver; absence of the module/driver means not affected.

Typical attack path

1. Obtain local access on a Qualcomm-based Linux or Android device where the qcom_battmgr / PMIC GLINK battery stack is present.
2. Cause or wait for PMIC GLINK protection-domain restart or service-up notifications that invoke qcom_battmgr_pdr_notify().
3. Concurrently trigger battmgr device teardown so the GLINK client is still listed while enable_work can still be queued.
4. Win the race so the workqueue worker uses battmgr after it is freed, producing a kernel use-after-free.
5. Result is typically a kernel oops or reboot; theoretical follow-on is local privilege escalation if freed memory is reclaimed and corrupted before the worker runs.

How to detect it

This is a local kernel use-after-free with no known in-the-wild campaign, so look for crash evidence rather than network indicators. Review kernel logs (dmesg, journalctl -k, pstore/console-ramoops, Android last_kmsg/tombstones, crash dumps) around device unbind, module teardown, or PMIC GLINK restarts for oops/BUG/KASAN use-after-free traces in qcom_battmgr, qcom_battmgr_pdr_notify, enable_work, or pmic_glink. Sudden reboots of Qualcomm devices without userspace explanation are a weak secondary signal. There are no named APT groups, ransomware families, file drops, or C2 patterns associated with this CVE. A clean boot log after patching with no matching oops does not prove historical exploitation, only that the bug is not currently firing.

• qcom_battmgr
• qcom_battmgr_pdr_notify
• pmic_glink
• enable_work
• Use-After-Free
• KASAN: use-after-free
• Unable to handle kernel paging request
• Oops:
• workqueue
• battmgr

What your security team should do

• Inventory Qualcomm Linux/Android/automotive/embedded images for qcom_battmgr / PMIC GLINK battery support; skip unrelated server fleets.
• Schedule kernel updates to versions that include the qcom_battmgr use-after-free fix in the next normal OEM/maintenance window—do not treat as a KEV-style emergency given EPSS ~0.002, no KEV, and no known exploit.
• Watch kernel logs and crash dumps on those devices for qcom_battmgr / PMIC GLINK workqueue oopses that could indicate the race being hit.
• If the driver is unused, keep it unloaded or disabled as defense in depth.
• Reassess only if exploit maturity, EPSS, or KEV status changes.