CVE-2026-89462

What it actually does

The MAX17040 fuel-gauge driver ignores regmap/I2C read failures in voltage (VCELL) and state-of-charge (SOC) helpers. On a failed transfer, an uninitialized register buffer is converted and reported through the power-supply get_property path as a valid reading. The poll worker can overwrite the last-known-good cached SOC with that garbage value and emit a spurious change event. Local userspace can therefore observe leftover kernel memory (information disclosure) and incorrect battery telemetry.

Why it matters to the business

Likelihood of widespread attack is low: EPSS is about 0.17% and flat over 30 days, the issue is not in CISA KEV, and there is no known exploit maturity or ransomware use. Residual risk is to Linux devices that actually use the MAX17040 gauge (embedded, mobile, and IoT). False charge or voltage readings can drive bad power-management decisions, unexpected shutdowns, or noisy monitoring alerts. Unprivileged local readers of battery sysfs may also obtain uninitialized kernel data. Treat as a routine kernel patch, not an emergency, unless battery-backed fleets depend on this driver.

How an attack unfolds

This is a local issue, not a remote network flaw. An attacker who can already run code or read power-supply attributes waits for or induces I2C failures to the MAX17040 (bus errors, device power-gate, contention). Because errors are dropped, subsequent voltage or capacity reads return converted uninitialized data instead of failing. The attacker harvests those values for a small kernel-memory leak and/or relies on a bogus SOC and spurious change events to confuse userspace power policy. No named threat actors or campaigns are associated with this CVE.

How to fix it

Apply the upstream Linux kernel fix that propagates regmap_read errors from max17040_get_vcell() and max17040_get_soc() through the power-supply get_property callback and retains the last valid cached SOC when polling fails. Upgrade to a distribution or vendor kernel that includes the CVE-2026-89462 patch. If the MAX17040 hardware is not present, blacklist or do not build the max17040 module. Until patched, restrict unprivileged access to power-supply sysfs where policy allows.

How to confirm the fix worked

Confirm the running kernel changelog or CVE mapping includes CVE-2026-89462, or inspect the max17040 driver for error returns from regmap_read in the VCELL/SOC paths and preservation of cached SOC on poll failure. On systems that load the driver, a failed I2C read should surface as a get_property error rather than a plausible voltage or capacity, and should not replace the last valid SOC or emit a capacity change event. Systems without MAX17040 hardware should not load the module.

Typical attack path

1. Gain local access on a Linux system whose kernel includes the unpatched max17040 power-supply driver
2. Identify the MAX17040-backed power-supply device via sysfs or kernel logs
3. Wait for or induce I2C/regmap read failures against the fuel gauge
4. Read voltage and capacity properties so uninitialized register data is converted and returned
5. Optionally consume spurious SOC change events or leaked values to influence local power-management logic

How to detect it

There is no public exploit and no KEV activity, so confirmed in-the-wild abuse is unlikely. Hunt for local processes repeatedly reading power-supply voltage or capacity around I2C error storms; kernel logs that mention max17040 or regmap/I2C transfer failures coincident with sudden SOC jumps or spurious power-supply change events; and audit of access to /sys/class/power_supply. Abrupt, physically implausible capacity or voltage samples after bus errors are a telemetry clue, not proof of attack. Uninitialized-memory disclosure leaves little durable forensic residue.

What your security team should do

• Patch Linux kernels that ship the max17040 driver; this is the complete fix
• Inventory whether max17040 is built, loaded, or bound to hardware before prioritizing rollout
• On devices that do not use this fuel gauge, blacklist the module to remove the code path
• Until patched, limit unprivileged reads of power-supply attributes where operationally feasible
• Do not treat this as KEV-level or ransomware-driven urgency; EPSS is low and unpublished exploit activity is not indicated
• Track distro kernel advisories for the exact package version that contains the fix