CVE-2026-89464

What it actually does

The TWL4030 charger driver allocates its private bci state with managed device resources. Two workqueue items (work and current_worker) dereference that state after remove(). twl4030_bci_remove() disables charging and masks interrupts but does not cancel those workers, so a pending worker can run after devm frees bci, causing a kernel use-after-free. A related race exists with the USB PHY notifier from devm_usb_get_phy_by_node(): the notifier is unregistered only after remove() returns, so cancelling work inside remove() can race a notifier-driven reschedule. The result is kernel memory corruption, an oops/panic in the power-supply path, or theoretically local privilege escalation if the freed object is reused under attacker control.

Why it matters to the business

Impact is limited to Linux systems whose hardware actually includes a Texas Instruments TWL4030 power-management companion (typically older OMAP-class embedded, industrial, or mobile boards), not general-purpose servers or desktops. Exploitation requires local ability to unbind or tear down the driver while work is queued, so remote unauthenticated compromise is not expected. EPSS is very low (~0.17%) and unchanged over 30 days, the CVE is not in CISA KEV, ransomware use is not reported, and exploit maturity is none about a month after publication. Residual risk is unexpected kernel crashes during driver teardown, module reload, or device unbind on unpatched TWL4030 fleets, plus the usual local UAF escalation concern on those same devices.

How an attack unfolds

An attacker needs local access on a machine that probes the TWL4030 charger, a way to queue the driver’s work items (charger or USB transceiver activity the driver already handles), and a teardown path—sysfs unbind, module unload, or device removal—before those workers finish. Historically remove() left the workers running, so they can execute against already-freed bci memory; the USB PHY notifier can also reschedule work across that window. Turning the race into reliable code execution requires controlling object reuse in kernel context on uncommon silicon and is not known to be weaponized. No public exploit, named APT, or ransomware campaign is associated with this issue; a successful trigger is far more likely to oops or reboot the device than to yield a turnkey privilege escalation.

How to fix it

Apply the upstream Linux kernel fix that registers the workers with devm_work_autocancel() and devm_delayed_work_autocancel() so they are cancelled during managed-resource release, before bci is freed, and in reverse registration order (current_worker first) so bci->work cannot reschedule current_worker after it is cancelled. Upgrade to a stable, LTS, distribution, or vendor kernel that contains that commit. Android, Yocto, and industrial BSPs need the corresponding vendor backport. There is no reliable configuration-only workaround other than avoiding runtime unbind or unload of twl4030_charger on unpatched kernels. Hosts that cannot probe TWL4030 hardware are unaffected.

How to confirm the fix worked

Confirm the running kernel includes the fix (devm_work_autocancel / devm_delayed_work_autocancel in the TWL4030 charger probe path, or a vendor changelog that cites the commit). Inventory images for the twl4030_charger module or TWL4030/OMAP platforms; systems that never load the driver are not exposed. After patching, unbind/rebind or reload the driver under charger or USB activity and verify dmesg shows no oops in twl4030 or power_supply code.

Typical attack path

1. Obtain local (or equivalent) access on Linux hardware that exposes the TWL4030 charger
2. Induce charger or USB PHY activity so the driver’s work and delayed work are queued
3. Force driver unbind, module unload, or device removal while those workers are still pending
4. A worker runs after bci is freed (or is rescheduled by the USB notifier across remove()), producing a kernel use-after-free
5. Memory corruption crashes the kernel or, in a tightly controlled local attempt, is abused toward privilege escalation

How to detect it

This use-after-free fires on driver teardown, not over the network. Search kernel logs (dmesg, journald, pstore/ramoops, panic dumps, kdump/vmcore, Android last_kmsg) around unexplained reboots for oops or panic stacks naming twl4030, twl4030_bci, twl4030_charger, or the power_supply charger path. Correlate with module unload or sysfs unbind of the TWL4030 charger (audit, udev, and /sys/module traces). Hosts without TWL4030 silicon or without the driver in the image cannot have been exploited this way. No public exploit payload, C2, or file-based IOCs are known.

• twl4030_charger
• twl4030_bci
• twl4030_bci_remove
• platform:twl4030_bci
• Unable to handle kernel paging request

What your security team should do

• Identify Linux images and embedded products that include twl4030_charger or TWL4030/OMAP hardware; deprioritize the rest of the fleet
• Patch affected kernels via distro or vendor updates; this is not a wide emergency given hardware specificity, stable low EPSS, no KEV listing, and no known exploit
• On unpatched TWL4030 devices, restrict unprivileged sysfs driver unbind and module unload
• Feed kernel oops/panic telemetry for twl4030_charger, twl4030_bci, and power_supply charger symbols into existing crash pipelines
• Watch vendor LTS, Android, and Yocto advisories for the backport rather than waiting for a generic server kernel bump