CVE-2026-90027 in Linux
Summary
by MITRE • 09/17/2026
In the Linux kernel, the following vulnerability has been resolved:
usb: typec: qcom-pmic-typec: disable cc_debounce_dwork on stop
cc_debounce_dwork is queued from the set_cc() and start_toggling() callbacks, which run from TCPM's kthread worker. port_stop() returns before tcpm_unregister_port() destroys that worker. Flushing the worker during unregister may therefore run a callback which queues the delayed work after port_stop() has returned.
The delayed work can then run after devres has freed pmic_typec_port.
Use disable_delayed_work_sync() in port_stop() to cancel a pending instance and prevent the TCPM callbacks from queueing another one.
This issue was found by an in-house static analysis tool.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 09/17/2026
The vulnerability identified within the Linux kernel's USB Type-C Qualcomm PMIC driver represents a classic use-after-free scenario arising from improper synchronization between resource lifecycle management and asynchronous workqueue execution. The core of the flaw lies in the sequence of operations during the device removal or port stop phase. Specifically, the cc_debounce_dwork delayed work item is queued by callbacks such as set_cc() and start_toggling(), which are executed within the context of the TCPM (Type-C Port Manager) kthread worker. When the system initiates a shutdown sequence for this specific hardware component, the port_stop function returns control to its caller before tcpm_unregister_port has completed the destruction of that underlying kthread worker. This temporal gap creates a race condition where the unregister process may proceed to flush or destroy the worker while callbacks are still potentially active or queued.
The critical consequence of this architectural oversight is that flushing the worker during the unregistration phase can inadvertently trigger a callback that queues another instance of the delayed work after port_stop has already returned and assumed responsibility for cleanup had passed. Consequently, when devres (device resource management) subsequently frees the pmic_typec_port structure to reclaim memory, any pending or newly queued cc_debounce_dwork items retain pointers to this now-freed memory region. If the kernel scheduler eventually executes these delayed work items, they will attempt to access invalid memory addresses, leading to a use-after-free condition that can result in system crashes, data corruption, or potentially exploitable arbitrary code execution depending on the state of the freed heap memory and the specific architecture involved.
This issue was originally detected by an in-house static analysis tool, highlighting the importance of automated verification for concurrency bugs involving kernel workqueues and device resource lifecycles. The vulnerability aligns with CWE-416, Use After Free, as it involves accessing a pointer after its associated memory has been deallocated. Furthermore, from a behavioral perspective related to ATT&CK techniques, this flaw facilitates potential exploitation vectors that could be categorized under privilege escalation or denial of service if an attacker can trigger the specific sequence of events leading to the race condition, although direct remote exploitability is limited by the physical requirement for hardware interaction in many contexts.
The resolution implemented involves modifying the port_stop function to utilize disable_delayed_work_sync() instead of relying solely on standard cancellation mechanisms that do not guarantee synchronization with pending executions. This change ensures that any currently running instance of the delayed work is allowed to complete, and no new instances are queued during the critical shutdown window. By explicitly cancelling the pending instance and preventing TCPM callbacks from queueing another one before the worker is safely destroyed, the driver guarantees that no deferred tasks will attempt to access the pmic_typec_port structure after it has been freed by devres. This synchronization fix effectively closes the race condition and restores memory safety within this subsystem.
To mitigate similar vulnerabilities in other kernel drivers or systems relying on asynchronous workqueues, developers should ensure strict ordering between resource deallocation and worker destruction. It is essential to synchronize with all pending delayed works before freeing associated data structures. Using functions like cancel_delayed_work_sync() or disable_delayed_work_sync() provides the necessary guarantee that no further executions will occur against freed memory. Additionally, employing static analysis tools during development can help identify these subtle timing issues early in the lifecycle, preventing them from reaching production kernels where they pose significant stability and security risks to the operating system integrity.