CVE-2026-98758 in Linux
Summary
by MITRE • 10/18/2026
In the Linux kernel, the following vulnerability has been resolved:
usb: typec: ucsi: glink: fix use-after-free of ucsi on remove
The pmic_glink client is released by the devres cleanup, which runs after pmic_glink_ucsi_remove() has returned, so its notification callbacks can queue work until then. Work that runs after ucsi_unregister() has been called touches freed state: it dereferences the connector array that ucsi_unregister() freed, or registers and unregisters the instance a second time.
Disable both work items with disable_work_sync() before unregistering, and unregister only if the instance is still registered.
This issue was found by an in-house static analysis tool.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 10/19/2026
The Linux kernel vulnerability identified as usb: typec: ucsi: glink: fix use-after-free of ucsi on remove represents a critical memory safety flaw within the USB Type-C UCSI GLink driver subsystem. This issue stems from improper synchronization between resource cleanup and asynchronous work queue execution during device removal operations. The core technical failure occurs because the pmic_glink client is released through devres (device resources) cleanup mechanisms, which are scheduled to run after the pmic_glink_ucsi_remove function has already returned control to its caller. This timing discrepancy creates a race condition where notification callbacks associated with the GLink interface can queue work items that execute subsequent to the ucsi_unregister call. Since ucsi_unregister is responsible for freeing critical data structures, including the connector array, any deferred work attempting to access these resources encounters freed memory, leading to undefined behavior and potential system instability.
From a technical perspective, this vulnerability exemplifies a classic use-after-free scenario where asynchronous operations outlive the lifetime of the objects they reference. The specific flaw involves two distinct failure modes: first, dereferencing the connector array after it has been deallocated by ucsi_unregister, which can lead to kernel panics or data corruption; second, attempting to register and unregister the instance a second time, which violates driver state machine expectations and may cause resource leaks or double-free conditions. The root cause lies in the lack of proper synchronization primitives to ensure that all pending work items are cancelled and completed before the associated resources are released. This is particularly dangerous because devres cleanup operates on a deferred basis, decoupling the actual deallocation from the explicit removal function return point.
The operational impact of this vulnerability can range from minor driver malfunction to severe system compromise depending on memory layout and exploit conditions. In typical scenarios, accessing freed kernel memory results in an immediate kernel oops or panic, causing a denial of service for systems relying on USB Type-C connectivity through GLink interfaces. However, sophisticated attackers could potentially leverage the use-after-free condition to achieve arbitrary code execution by controlling the contents of the reclaimed memory region before it is reallocated for other purposes. This would allow escalation from user space to kernel ring privileges, providing full control over the affected system. The vulnerability affects systems utilizing Qualcomm PMIC GLink interfaces with USB Type-C controllers that depend on UCSI notifications and asynchronous work processing during device teardown sequences.
Mitigation strategies must address both immediate remediation and long-term architectural improvements. The primary fix involves disabling all pending work items using disable_work_sync before calling ucsi_unregister, ensuring that no further callbacks can be queued or executed after the unregister process begins. Additionally, the driver should verify if the instance is still registered before attempting to unregister it again, preventing double-unregister errors. For system administrators unable to apply kernel patches immediately, disabling the affected USB Type-C GLink functionality through device tree overlays or module blacklisting may reduce exposure. Long-term solutions require implementing stricter lifecycle management for asynchronous work items in driver code, ensuring that all deferred operations are synchronized and completed prior to resource deallocation. This aligns with secure coding practices recommended by industry standards such as CWE-416 (Use After Free) and ATT&CK techniques related to privilege escalation via memory corruption vulnerabilities. Developers should also consider adopting static analysis tools similar to the one used for discovery, integrating them into continuous integration pipelines to catch synchronization issues early in the development lifecycle.