CVE-2026-100079

The Linux kernel's USB Type-C UCSI driver core fails to release a resource at the end of its lifetime (CWE-772): per-instance debugfs directories created in ucsi_register() are only removed at ucsi_destroy() time, not in ucsi_unregister(). On drivers that unregister and re-register the same UCSI instance across a remoteproc restart — such as Qualcomm's ucsi_glink (pmic_glink.ucsi.0) — the kernel then tries to create a debugfs directory that already exists, logging an error, leaving stale entries, and, per the fix, risking an unsafe repeated unregister path against a freed ucsi->debugfs pointer. The CVSS 3.1 score is 5.5 (medium) with local attack vector, low privileges required, and high availability impact only — an attacker with local low-privileged access could at most degrade or crash the system; there is no confidentiality or integrity impact. Affected systems are Linux machines running kernels with the buggy UCSI teardown code, with the named trigger being Qualcomm Snapdragon-class platforms using the pmic_glink UCSI transport. No public proof of concept is known, the flaw is not on the CISA KEV, and there is no evidence of exploitation in the wild.

What to do: Upgrade to a kernel build that carries the upstream fix, which moves debugfs cleanup into ucsi_unregister() and nulls ucsi->debugfs after freeing; apply your distribution's updated kernel packages when available (Debian, for example, shipped kernel fixes in its recent large update). No configuration workaround is required, but administrators of Qualcomm/Snapdragon systems can grep kernel logs for "debugfs: 'pmic_glink.ucsi.0' already exists in 'ucsi'" as an indicator the buggy path has been hit. Risk is limited to local availability, so this can be patched on a normal maintenance cycle rather than treated as an emergency.