Live › vulnerability › CVE-2026-98691
Go to dashboardWhen the Thunderbolt domain stops, a DisplayPort tunnel that has not yet come up keeps its completion work queued against a domain that is already torn down. The work can run against freed state and holds a reference that delays driver unbind until a timeout expires.
Summary written from the sources below. Check the originals before acting.
First seen by InfraStack 2026-10-23 21:57 UTC. All times on this page are UTC.
Systems with Thunderbolt or USB4 ports running a Linux kernel with the thunderbolt driver, where a DisplayPort tunnel is being set up while the domain is stopped. Systems without Thunderbolt hardware, or with the thunderbolt driver not loaded, are not affected. The sources do not say which kernel versions carry the fix.
No product ranges from the sources yet.
Unknown from the sources.
Unknown from the sources.
Each row is the first time that source carried this signal. The analyst’s rows are its own findings.
In the Linux kernel, the following vulnerability has been resolved:
thunderbolt: Tear down inactive DP tunnels when the domain is stopped
tb_stop() only tears down DMA tunnels so a DP tunnel that is still waiting for dprx_work to complete keeps that work queued while the routers are removed and the control channel is stopped. The work only stops once the DPRX timeout has passed and because it requeues itself until then the flush_workqueue() in tb_domain_remove() won't wait for its final run. The callback then runs against a domain that is already torn down. A reference to that domain is kept so the completion waiting for that domain to disappear in unbind will block until the timeout is eventually reached.
Tear down DP tunnels that are not active yet as well which also cancels that work. Tunnels for displays that are already alive are untouched and keep working.
This page as .md · .json · in your agent: get_signal("CVE-2026-98691")
NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.