CVE-2026-98690: thunderbolt: Fix domain reference leak when DPRX read is canceled
In the Linux kernel, the following vulnerability has been resolved:
thunderbolt: Fix domain reference leak when DPRX read is canceled
tbtunnelonedp() takes a domain reference which is only dropped once tbdptunnelactive() has run on the work queue. If that work is cancelled that reference is leaked. Since commit f5cc545f5969 ("thunderbolt: Wait for tbdomainrelease() to complete when driver is removed") instead of just leaking memory this now also blocks in the completion wait forever when unbinding the driver.
This can be triggered whenever a DP tunnel is torn down before the DPRX read has completed, e.g. by unplugging within the timeout, and then unbinding the driver.
That reference only exists to keep the domain around while the DPRX work is scheduled so let the work itself own it: take it in tbdpdprxstart() and drop it in both places that end the work. Get/put are then paired inside the same file and it doesn't matter anymore if the callback ever runs.
Affected Software
Event History
Frequently Asked Questions
What conditions can trigger the affected behavior?
It can occur when a DisplayPort tunnel is torn down before its DPRX read completes, such as when a device is unplugged within the read timeout. The problem becomes visible if the Thunderbolt driver is then unbound.
What is the operational impact of the reference leak?
The leaked domain reference can cause unbinding the Thunderbolt driver to wait forever for domain release to complete. This is more than a memory leak in kernels containing the change that waits for tb_domain_release() during driver removal.
How can an administrator recognize that a system may be affected?
A likely symptom is a Thunderbolt driver unbind operation that hangs indefinitely after a DisplayPort tunnel was disconnected or otherwise torn down during a pending DPRX read.