CVE-2026-100079 in Linux
Summary
by MITRE • 09/25/2026
In the Linux kernel, the following vulnerability has been resolved:
usb: typec: ucsi: unregister debugfs entries on teardown
ucsi_register() creates per-instance debugfs entries, but ucsi_unregister() keeps them around until ucsi_destroy().
Drivers like ucsi_glink that unregister/register the same UCSI instance across remoteproc restart then try to create an already existing debugfs directory and log:
debugfs: 'pmic_glink.ucsi.0' already exists in 'ucsi'
Unregister debugfs entries as part of ucsi_unregister(), and clear ucsi->debugfs after freeing it so repeated unregister paths remain safe.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/25/2026
The vulnerability identified within the Linux kernel's USB Type-C UCSI subsystem stems from an improper resource management lifecycle during driver teardown operations. Specifically, the issue resides in the interaction between the registration and unregistration functions for Universal Charge Specification Interface (UCSI) instances. When a UCSI instance is initialized via ucsi_register(), the system creates specific debugfs entries to facilitate debugging and diagnostics for that particular hardware instance. However, the corresponding cleanup function, ucsi_unregister(), was historically designed only to disable or logically detach the interface without removing these associated filesystem nodes from the kernel's virtual file system structure. These debugfs artifacts were left lingering in memory until a later destruction phase handled by ucsi_destroy(). This architectural oversight creates a significant discrepancy between the logical state of the driver and its physical representation in the debug filesystem, leading to resource leaks and subsequent operational failures during dynamic reconfiguration scenarios.
This flaw has severe implications for systems utilizing drivers that manage UCSI instances across remoteproc restarts or hot-plug events where unregistration and immediate re-registration occur rapidly. A prime example is the ucsi_glink driver, which operates in environments requiring frequent processor resets or state transitions. When such a driver attempts to unregister an existing instance and then immediately register it again, the system encounters a conflict because the debugfs directory created during the initial registration was never removed. The kernel logs an error indicating that the path pmic_glink.ucsi.0 already exists within the ucsi namespace. This not only pollutes the debug filesystem but can also cause subsequent initialization attempts to fail or behave unpredictably, potentially disrupting power delivery negotiations and USB role switching functionalities critical for device operation.
From a security and stability perspective, this issue aligns with CWE-401, which describes missing release of memory after successful allocation, although in this context it manifests as stale file system entries rather than raw heap memory leaks. The failure to clean up resources properly can lead to Denial of Service conditions if the accumulation of such errors causes driver initialization loops or kernel warnings that degrade system performance over time. Furthermore, leaving debug interfaces active when they should be dormant violates best practices for minimizing attack surfaces, as per ATT&CK technique T1083 File and Directory Discovery, where an attacker might exploit lingering diagnostic entries to gather information about the system's internal state even after a service has ostensibly stopped running. The persistence of these nodes provides unnecessary visibility into kernel internals that should be transient during normal operational cycles involving driver reloads or hardware resets.
The resolution involves modifying the ucsi_unregister() function to explicitly remove all debugfs entries associated with the instance before completing the unregistration process. Additionally, the implementation ensures that the pointer referencing the debugfs directory is cleared after it is freed. This dual action guarantees idempotency in the teardown sequence, meaning that repeated calls to unregister and register functions will not encounter state conflicts or resource collisions. By ensuring that ucsi_unregister() fully cleans up its footprint, the kernel maintains a consistent view of active hardware instances versus those being removed.
To mitigate this vulnerability, system administrators and developers should ensure that their Linux kernels are updated with patches addressing this specific UCSI debugfs cleanup logic. For environments where remoteproc restarts or dynamic driver reloading are common practices, applying these updates is critical to maintaining stable USB Type-C functionality. Developers integrating custom drivers based on the UCSI framework must adhere strictly to the corrected lifecycle patterns, ensuring that all allocated resources, including virtual file system entries, are released during the unregistration phase rather than deferring this task to a later destruction callback. This approach prevents resource accumulation and ensures robust behavior across hardware state transitions.