CVE-2026-98693: thunderbolt: Hold a router reference for each allocated HopID
In the Linux kernel, the following vulnerability has been resolved:
thunderbolt: Hold a router reference for each allocated HopID
tbstop() drops the reference to all DP tunnels but does not deactivate them, thus nothing cancels a dprxwork still in flight (which holds its own tunnel reference) and the tunnel can outlive tbswitchremove(). The HopID releases in tbpathfree() then operate on freed IDAs and trigger warnings like
idafree called for id=8 which is not allocated.
This can be triggered by unbinding the driver while a DP tunnel is still waiting for the DPRX capabilities read to finish. On the Apple NHI unplugging the cable runs into just that reliably because the read can never finish right now and because the unplug powers down the entire USB4 complex and removes the NHI device.
Take a router reference whenever an input or output HopID is allocated and drop it again after the HopID is released. This keeps the ports and their HopID IDAs alive for as long as they are used.
The KUnit tests allocate routers without ever registering their devices so initialize the embedded struct device there as well and drop its initial reference when the test is finished.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Compensating control
In the Thunderbolt code, take a router reference whenever an input or output HopID is allocated, and drop that reference after the HopID is released so the ports and their HopID IDAs remain alive while in use.
- Compensating control
In the KUnit tests, initialize the embedded struct device for allocated routers and drop its initial reference when each test finishes.
Event History
Frequently Asked Questions
What conditions are needed to trigger this issue?
A DisplayPort tunnel must still be waiting for its DPRX capabilities read to complete when the Thunderbolt driver is unbound or the associated router is removed. The resulting in-flight work can outlive router removal and later release HopIDs against freed IDA structures.
Which hardware scenario is specifically reported to trigger it reliably?
The issue is reported to occur reliably on Apple NHI hardware when a cable is unplugged. In that situation, the DPRX capabilities read cannot finish, while unplugging powers down the USB4 complex and removes the NHI device.
What is the observable symptom of an affected system?
Kernel warnings can report that ida_free was called for a HopID that is not allocated, such as "ida_free called for id=8 which is not allocated." This occurs when delayed HopID cleanup operates on IDAs that have already been freed.