CVE-2026-89461

What it actually does

A race in the Linux kernel MAX17040 fuel-gauge (power-supply) driver lets delayed polling work keep running across system suspend. cancel_delayed_work() only drops a pending instance and does not wait for max17040_work that is already executing, so the callback can still access the gauge and re-queue itself after the suspend callback has returned. That can yield unsynchronized hardware access during power-state transitions, inconsistent driver state, and kernel warnings or oops on systems that bind this driver.

Why it matters to the business

Impact is confined to Linux devices with a Maxim MAX17040-class fuel gauge (typically laptops, tablets, and embedded or IoT products), where suspend/resume may fail, battery status may be wrong, or the kernel may oops and force a reboot. Typical enterprise servers without this hardware are unaffected. The flaw is not in CISA KEV, has no ransomware association, exploit maturity is none, and EPSS is about 0.21% with no 30-day increase, so urgency is low except for OEMs and fleets that depend on stable sleep on this chip.

How an attack unfolds

An attacker needs local access on a machine where the max17040 driver is bound, plus the ability to induce system suspend while the poll work is in flight. They race freeze against the workqueue so the callback outlives the suspend path and continues I/O or re-queues work after polling was supposed to stop. The realistic result is denial of service or flaky power management, not a reliable remote or privilege-escalation primitive. No public exploit, named threat actor, or campaign is associated with this issue.

How to fix it

Apply the upstream Linux kernel change that uses cancel_delayed_work_sync() in the max17040 suspend path so polling is fully quiesced before suspend completes, then deploy a distro or vendor kernel that includes that fix. Until then, avoid depending on suspend on affected MAX17040 devices where practical, or unload/blacklist the max17040 module if the hardware is unused. Confirm via kernel changelog or driver source that the suspend path waits for in-flight work.

How to confirm the fix worked

Confirm the running kernel includes the max17040 suspend-synchronization fix (advisory, changelog, or driver source showing cancel_delayed_work_sync). On a test unit with the gauge, repeat suspend/resume under load and verify dmesg/journal show no max17040 oops, workqueue warnings, or I2C/power-supply errors. lsmod and power-supply sysfs show whether the driver is bound; systems without the module or hardware are not exposed.

Typical attack path

1. Gain local access to a Linux system that loads the max17040 power-supply driver
2. Keep the delayed fuel-gauge poll work active
3. Trigger system suspend so it races with an in-flight max17040_work callback
4. Allow the worker to touch the gauge or re-queue after suspend believes polling has stopped
5. Cause driver-state corruption, failed resume, or a kernel oops that disrupts the device

How to detect it

There is no network signature. Review host kernel logs (dmesg, journalctl -k, pstore/console-ramoops) around suspend and resume for oops or warnings that name max17040_work or the max17040 driver, and for I2C or power-supply errors coincident with sleep. Repeated suspend abort or resume failure on MAX17040 hardware is a behavioral clue that the race fired. Absence of crashes does not prove the window was never hit; patch level is the reliable exposure check. No named actors are tracking this CVE.

• max17040_work
• max17040
• drivers/power/supply/max17040_battery.c

What your security team should do

• Inventory Linux endpoints and embedded images that ship or load max17040 and treat those as the only in-scope assets
• Patch to a vendor/distro kernel that synchronizes max17040 work cancellation on suspend; no KEV deadline applies
• Until patched, watch suspend/resume failures and max17040-related kernel logs on mobile and embedded estates
• Unload or blacklist max17040 where the fuel gauge is absent or unused
• Do not run an emergency out-of-band campaign solely for this CVE given exploit maturity None and stable low EPSS