CVE-2026-89463 in Linux
Summary
by MITRE • 09/12/2026
In the Linux kernel, the following vulnerability has been resolved:
power: supply: ucs1002: fix use-after-free on remove
ucs1002 has no remove callback, so unbind runs entirely through devm. The alert IRQ handler queues the health_poll delayed work, and the work reschedules itself while the chip reports a bad-health condition. devm frees the alert IRQ, which only synchronizes the handler; it does not cancel the delayed work, which can then run after devm frees the driver data and dereference it.
Register health_poll with devm_delayed_work_autocancel() before the alert IRQ is requested. devm then frees the IRQ before cancelling the work, so the handler can no longer queue it and the work is cancelled before the driver data is freed.
This issue was found by an in-house static analysis tool.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/12/2026
The vulnerability identified within the Linux kernel's power supply subsystem for the UCS1002 charger IC represents a classic use-after-free condition arising from improper resource management during device removal. The core of the issue lies in the lifecycle mismatch between hardware interrupt handling and driver data deallocation. When the system initiates an unbind or remove operation, it relies on managed resources (devm) to handle cleanup automatically. However, because the UCS1002 driver lacks a dedicated remove callback, the entire teardown process is delegated to devm mechanisms. While devm correctly synchronizes and frees the alert interrupt request line, it does not inherently manage kernel delayed work structures that may have been scheduled by the interrupt handler prior to deallocation.
The operational flaw manifests when the UCS1002 chip reports a bad health condition, triggering an alert IRQ. The associated interrupt handler queues a delayed work item named health_poll to monitor and report this state continuously. This work item is designed to reschedule itself if the unhealthy condition persists. If the device is removed while such a pending or running work item exists, devm proceeds to free the driver's private data structures after synchronizing with the IRQ handler. Since synchronization only ensures that any currently executing interrupt context has finished and prevents new interrupts from being delivered, it does not cancel already queued delayed work items. Consequently, when the health_poll worker eventually executes, it attempts to dereference pointers within the now-freed driver data structure, leading to a use-after-free vulnerability.
This type of memory corruption can lead to severe security implications, including kernel panics that cause system instability or denial of service. More critically, if an attacker can influence the timing of device removal relative to health alerts, they might exploit the dangling pointer to execute arbitrary code with kernel privileges by overwriting freed memory structures with controlled data. The vulnerability was originally detected through static analysis tools designed to identify such lifecycle mismatches and improper resource tracking patterns in complex driver architectures.
To mitigate this issue, the fix involves restructuring the initialization sequence of the health monitoring mechanism relative to the interrupt request registration. By registering the delayed work item using devm_delayed_work_autocancel before requesting the alert IRQ, the kernel's managed resource framework ensures that the work is automatically cancelled during device removal prior to any data deallocation. This guarantees that when devm frees the driver data, no pending or active worker threads remain that could access those freed memory regions. The interrupt handler can still queue new work items if an alert occurs after registration but before cancellation; however, since the IRQ itself is freed and synchronized first, no new work will be queued during the critical window between IRQ disablement and data freeing. This approach aligns with best practices for managing asynchronous tasks in kernel drivers to prevent race conditions and memory safety violations.
From a standards perspective, this vulnerability corresponds to CWE-416: Use After Free, which describes situations where a program continues to use a pointer after it has been freed, leading to undefined behavior. In the context of attack vectors, this scenario relates to ATT&CK technique T1059.007: Command and Scripting Interpreter via Kernel Modules or Drivers if exploitation leads to privilege escalation, although primarily it serves as an initial vector for system instability (T1429: Resource Hijacking). The resolution emphasizes the importance of leveraging managed resource APIs like devm not just for simple allocations but also for complex asynchronous constructs such as delayed work items. Developers must ensure that all asynchronous operations tied to a device's lifecycle are explicitly cancelled or bound to the same cleanup scope as the underlying hardware resources they depend on, thereby maintaining memory integrity throughout the device removal process.