CVE-2026-98758: usb: typec: ucsi: glink: fix use-after-free of ucsi on remove
In the Linux kernel, the following vulnerability has been resolved:
usb: typec: ucsi: glink: fix use-after-free of ucsi on remove
The pmicglink client is released by the devres cleanup, which runs after pmicglinkucsiremove() has returned, so its notification callbacks can queue work until then. Work that runs after ucsiunregister() has been called touches freed state: it dereferences the connector array that ucsiunregister() freed, or registers and unregisters the instance a second time.
Disable both work items with disableworksync() before unregistering, and unregister only if the instance is still registered.
This issue was found by an in-house static analysis tool.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 6.12.113 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 6.18.56 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 7.2.10 - Compensating control
In the usb: typec: ucsi: glink remove path, disable both work items with disable_work_sync() before calling ucsi_unregister(), and unregister only if the instance is still registered.
Event History
Frequently Asked Questions
Which systems are exposed to this issue?
Systems using the Linux kernel's USB Type-C UCSI GLINK driver are exposed. The problem occurs during removal of the PMIC GLINK UCSI instance, when notification callbacks can still queue work after UCSI state has been unregistered.
What condition is needed to trigger the use-after-free?
The UCSI GLINK device must be removed while PMIC GLINK notification callbacks are still able to queue either of the driver's work items. Work executing after ucsi_unregister() can then access the freed connector array or attempt to register and unregister the instance again.
What mitigation is indicated if the fix cannot be applied immediately?
The provided data does not identify a configuration workaround. The remediation is to ensure both work items are disabled synchronously before UCSI unregistering and to unregister only when the instance remains registered.