CVE-2026-64329: usb: typec: ucsi: ccg: Fix use-after-free of ucsi on remove
In the Linux kernel, the following vulnerability has been resolved:
usb: typec: ucsi: ccg: Fix use-after-free of ucsi on remove
The threaded IRQ handler ccgirqhandler() calls ucsinotifycommon(), which on a connector-change event calls ucsiconnectorchange() and schedules connector work. In ucsiccgremove(), ucsidestroy() frees uc->ucsi (kfree) before freeirq() is called, so a handler invocation already in flight may access the freed object after ucsidestroy().
CPU 0 (remove) | CPU 1 (threaded IRQ) ucsidestroy(uc->ucsi) | ccgirqhandler() kfree(ucsi) // FREE | ucsinotifycommon(uc->ucsi) // USE
Move freeirq() before ucsidestroy() in the remove path. It is kept after ucsiunregister(): ucsiunregister() cancels connector work whose handler issues GETCONNECTORSTATUS through ucsisendcommandcommon(), which waits for a completion that is signalled from the IRQ handler, so the IRQ must stay active until that work has been cancelled.
The probe error path already orders freeirq() before ucsidestroy().
This bug was found by static analysis.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Compensating control
In the Linux kernel UCSI UCSI CCG remove path, ensure the threaded IRQ remains active until all in-flight connector work scheduled via ucsi_notify_common() is cancelled. Specifically, move free_irq() before ucsi_destroy() so that ccg_irq_handler() cannot run after the ucsi object has been freed (ucsi_destroy/ucsi_unregister).
Event History
Frequently Asked Questions
What systems are exposed to this issue?
Systems using the Linux kernel CCG UCSI USB Type-C driver are exposed during device removal if a threaded IRQ handler is still in flight. The affected path involves connector-change handling and UCSI connector work.
What level of access does exploitation require?
The CVSS vector rates the issue as locally exploitable with low privileges and no user interaction. It assigns high confidentiality, integrity, and availability impact.
What is the required fix in the driver removal path?
The IRQ must be freed before the UCSI object is destroyed, preventing an in-flight threaded handler from accessing freed memory. The IRQ should remain active until after ucsi_unregister(), because unregistering cancels work that may require IRQ-delivered command completion.
How can maintainers identify the vulnerable code ordering?
Inspect the CCG UCSI remove path for ucsi_destroy() being called before free_irq(). The safe ordering is free_irq() before ucsi_destroy(), while retaining free_irq() after ucsi_unregister().