CVE-2026-89466

What it actually does

The Qualcomm battery-manager driver copies firmware Pascal-style strings into adjacent fixed-size kernel buffers (model_number, serial_number, and oem_info) and, on the SC8280XP path, may omit a NUL terminator when firmware fills the entire field. Those buffers are exported to userspace as power-supply string properties and formatted with unbounded %s, so a full-length unterminated string over-reads neighboring members and can continue past the structure, disclosing kernel memory and risking an oops or hang. Integrity is not affected; impact is confidentiality and availability of the local kernel and power-supply interface.

Why it matters to the business

Linux devices that load the Qualcomm battery manager can leak device identifiers and adjacent kernel memory to any local process that reads ordinary battery attributes, and an over-read may disrupt power-supply reporting. The vector is local with no extra privileges required, but there is no remote wormability. Exploitation maturity is none, EPSS is very low and flat (~0.0014 over 30 days), the CVE is not in CISA KEV, and no ransomware use is reported. About a month after publication, treat this as a scheduled high-severity local kernel patch on Qualcomm-based Linux laptops, compute modules, and embedded images rather than an internet-facing emergency.

How an attack unfolds

An attacker with local access does not need elevated privileges. They read power-supply class string attributes that qcom_battmgr populated from firmware. If firmware supplied a maximum-length unterminated string, kernel-side %s formatting walks into the next packed fields and returns extra bytes to the caller. The attacker inspects the oversized or concatenated output for leaked serials, OEM data, or residual kernel contents and uses that only for local reconnaissance. There is no remote path, credential bypass, or memory write, and no named threat actors or campaigns are associated with this issue.

How to fix it

Install a distribution or SoC-vendor kernel that includes the qcom_battmgr change to copy firmware strings with strscpy() so model_number, serial_number, and oem_info are always NUL-terminated, matching the existing SM8350 path. If a package is not yet available, backport the upstream fix in the Qualcomm battery-manager driver and rebuild. No complete configuration workaround preserves the interface; until patched, restrict untrusted local code and containers from the power-supply sysfs tree. Exact packaged version numbers were not supplied with this record, so map the fix via vendor kernel changelogs.

How to confirm the fix worked

Confirm the running kernel’s changelog, stable/LTS mapping, or driver source/debug symbols include strscpy() termination in the SC8280XP battery-manager string copy. After reboot, power-supply string properties must be bounded C strings with no bleed of model, serial, or OEM fields into one another, and expected Qualcomm battery attributes should still enumerate. Hosts that never load qcom_battmgr are not exposed. Compare pre- and post-patch reads of the same attributes to ensure over-long or concatenated values no longer appear.

Typical attack path

1. Obtain local access to a Linux host whose kernel still uses the unpatched qcom_battmgr SC8280XP string-copy path
2. Enumerate power-supply class entries backed by the Qualcomm battery manager
3. Read exported string properties (model, serial, OEM info) that userspace formats from unterminated kernel buffers
4. Recover adjacent field contents or residual kernel memory from the over-read output
5. Use leaked identifiers or memory solely for further local reconnaissance

How to detect it

No public exploit tooling or named-actor activity is known, so hunts are host-centric. Review auditd, LSM, or equivalent file-access logs for unusual or bulk reads of Qualcomm power-supply sysfs string attributes by processes other than normal power daemons, especially from unprivileged users, containers, or short-lived binaries. Kernel logs around power_supply and qcom_battmgr for oopses or faults during property reads may indicate an over-read that hit unmapped memory. Captured sysfs values that are over-long or concatenate model, serial, and OEM fields indicate exposure, not a unique malware signature. Memory of processes that scraped the power-supply class is the most realistic place to see whether adjacent fields were collected. Network IOCs do not apply.

What your security team should do

• Inventory Linux images that load qcom_battmgr (Qualcomm SC8280XP-class laptops, modules, and embedded boards) and apply vendor kernel updates containing the string-termination fix
• Do not treat this as a fleet-wide remote emergency: EPSS is negligible and unchanged, exploit maturity is none, and it is not in CISA KEV or known ransomware playbooks
• Until patched, limit untrusted users and containers from power-supply sysfs and avoid passing those attributes into untrusted namespaces
• Track OEM/distro advisories for the precise backport; bundle with other high local-kernel fixes unless multi-tenant Qualcomm hosts make local info leaks unacceptable
• After patching, verify the battery driver still loads and userspace power management continues to read model/serial attributes cleanly