CVE-2026-90026 in Linux
Summary
by MITRE • 09/16/2026
In the Linux kernel, the following vulnerability has been resolved:
usb: typec: qcom-pmic: cancel reset_work on stop
pdphy_stop() disables IRQs but leaves reset_work pending. If the IRQ handler schedules it just before disable_irq(), the work runs after remove() frees the struct via devm.
Call cancel_work_sync() after disabling IRQs to close the window.
This issue was found by an in-house static analysis tool.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/16/2026
The identified vulnerability resides within the Qualcomm PMIC Type-C driver subsystem of the Linux kernel, specifically affecting the power delivery physical layer interface management. The core technical flaw is a race condition involving asynchronous work queue execution and device resource lifecycle management. When the pdphy_stop function is invoked to halt the USB Type-C port operation, it proceeds to disable hardware interrupts via disable_irq(). However, this action does not guarantee that pending or newly scheduled kernel work items are immediately halted. Specifically, if an interrupt handler triggers the scheduling of reset_work at a precise moment just before the irq_disable call completes, there exists a critical window where the work item remains queued for execution even after the driver's removal routine has begun freeing its associated data structures using devm managed resources.
This timing discrepancy leads to a use-after-free scenario, which is classified under CWE-416 in industry standard vulnerability taxonomies. Once the remove function executes and releases the memory allocated for the device structure via devm, any subsequent execution of reset_work will attempt to access freed memory. This results in undefined behavior that can manifest as kernel panics, data corruption, or potentially exploitable conditions where an attacker might leverage the corrupted state to achieve arbitrary code execution with kernel privileges. The vulnerability is particularly insidious because it relies on a narrow timing window during device removal, making it difficult to reproduce consistently without specific hardware load patterns or stress testing tools that can trigger rapid interrupt scheduling concurrent with driver unbinding operations.
From a threat modeling perspective aligned with the MITRE ATT&CK framework for enterprise environments, this flaw falls under the category of Privilege Escalation via Local Exploitation. Although it requires physical access or local user privileges to load and unload kernel modules in many configurations, successful exploitation could allow an unprivileged process to crash the system (Denial of Service) or escalate privileges by manipulating memory corruption states. The root cause is identified as improper synchronization between interrupt handling contexts and work queue cancellation mechanisms, a common pitfall in complex driver architectures where hardware state transitions must be strictly synchronized with software resource management.
The resolution implemented involves calling cancel_work_sync immediately after disabling interrupts within the pdphy_stop routine. This function ensures that any previously scheduled reset_work is not only cancelled but also fully completed by waiting for its execution to finish before proceeding. By closing this race window, the driver guarantees that no work items will execute against freed memory structures during or after device removal. To mitigate similar issues in broader kernel development practices, developers should adhere strictly to patterns where resource cleanup routines explicitly synchronize with all asynchronous tasks associated with the device. Utilizing static analysis tools like those mentioned in the discovery process can help identify such race conditions early in the development lifecycle, ensuring that interrupt disablement is always paired with synchronous cancellation of dependent work items to maintain memory safety and system stability.