CVE-2026-89463

What it actually does

Use-after-free in the Linux kernel UCS1002 power-supply driver on device unbind/remove. The alert IRQ handler queues self-rescheduling delayed work (health_poll); unbind runs entirely through devm, which frees the IRQ (synchronizing only the handler) and then frees driver data without cancelling that work. The leftover work can run against freed kernel memory, causing an oops/panic and, if the freed object were reused in a controlled way, potential local kernel memory corruption.

Why it matters to the business

Risk is concentrated on Linux hosts that actually bind the UCS1002 USB power-supply chip and that unbind, unload, or hot-remove that driver. Primary consequence is availability (unexpected kernel crash or reboot), not data theft. The issue is not in CISA KEV, is not tied to ransomware, has no known public exploit (maturity None), and EPSS remains very low and flat (~0.0021 with 0% change over 30 days, published about 31 days ago). Treat as routine kernel patching, not an emergency outage driver.

How an attack unfolds

A local actor on a system with the ucs1002 driver bound waits until the chip reports a bad-health condition so health_poll delayed work is queued and keeps rescheduling. They then trigger unbind (sysfs unbind, module removal, or device detach). Because there is no remove callback, teardown is purely devm-ordered: the alert IRQ is released without cancelling the work, driver data is freed, and the leftover work later dereferences that freed memory. That typically yields a kernel oops. Turning the race into reliable privilege escalation would require additional kernel-heap control and is not known to have been demonstrated; no named threat actors are associated with this CVE.

How to fix it

Apply the upstream kernel change that registers health_poll with devm_delayed_work_autocancel() before the alert IRQ is requested, so teardown cancels the work after IRQ free and before driver data is released. Upgrade to a distribution or vendor kernel whose changelog includes the UCS1002 use-after-free-on-remove fix for this issue. If a patched kernel cannot be deployed immediately, do not unbind or unload ucs1002, restrict write access to driver unbind/unbind sysfs and module unload, and avoid hot-removing the device. Exact distro package versions were not supplied; follow your kernel vendor’s advisory once published.

How to confirm the fix worked

Confirm the running kernel includes the ucs1002 health_poll autocancel fix (package changelog, vendor CVE mapping, or driver source showing devm_delayed_work_autocancel for health_poll before the alert IRQ is requested). After upgrade, unbind/rebind or safely remove/reprobe the power-supply device under a bad-health condition and verify no oops, UAF warning, or work-queue activity after detach in dmesg/journal. Hosts without UCS1002 hardware should not load this driver.

Typical attack path

1. Obtain local access to a Linux host where the ucs1002 driver is bound to a UCS1002 power-supply device
2. Cause or wait for a bad-health condition so the alert path queues self-rescheduling health_poll delayed work
3. Trigger driver unbind or removal while that delayed work is pending (sysfs unbind, module unload, or hot-unplug)
4. Win the race so health_poll runs after devm has freed driver data
5. Induce a kernel oops/panic, or attempt to reuse the freed object for further local kernel compromise

How to detect it

There is no public exploit or named actor activity; look for accidental or local abuse after the fact in kernel logs rather than network telemetry. Review dmesg, journalctl -k, /var/log/kern.log, kdump/vmcore, and panic console output around driver unbind for oops/UAF/paging-request traces that mention ucs1002 or health_poll, and for work-queue execution after the driver was unbound. Correlate with writes to driver unbind sysfs or rmmod/modprobe of ucs1002. Absence of those artifacts does not prove non-exploitation, but this issue was found by static analysis and is unlikely to leave distinctive network IOCs.

• ucs1002
• health_poll
• power_supply: ucs1002
• Unable to handle kernel paging request
• use-after-free
• Workqueue:
• echo .* > .*/drivers/ucs1002/unbind
• rmmod ucs1002

What your security team should do

• Inventory Linux fleets for kernels that ship the ucs1002 driver and for hardware that actually binds it; deprioritize systems without that device
• Schedule a standard kernel update to a build that contains the UCS1002 delayed-work autocancel fix; this is not KEV-driven and EPSS is stable and low
• Until patched, restrict who can unbind drivers or unload modules and avoid administrative unbind of ucs1002
• Watch kernel logs for ucs1002/health_poll oopses around unbind, but do not treat this as an active campaign indicator
• Re-scan after patching to confirm the vulnerable driver build is gone