CVE-2026-98691 in Linux
Summary
by MITRE • 10/18/2026
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.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 10/18/2026
The Linux kernel thunderbolt driver contains a synchronization flaw within its domain teardown sequence, specifically affecting DisplayPort tunnel management during device removal or system shutdown scenarios. The core issue resides in the tb_stop function, which is responsible for terminating active connections when a Thunderbolt domain is being dismantled. While this routine correctly handles and tears down Data Transfer Protocol (DTP) tunnels that facilitate DMA operations, it fails to address DisplayPort (DP) tunnels that are currently inactive or waiting for initialization completion. This oversight creates a race condition where the underlying hardware routers and control channels are removed from the system before all associated kernel work items have been properly finalized.
When a DP tunnel is not yet active but has queued work via dprx_work, this task remains pending in the kernel workqueue even as the domain structure begins to be destroyed. The tb_domain_remove function attempts to clean up resources by calling flush_workqueue, expecting all worker threads to complete their tasks before proceeding with memory deallocation and hardware deregistration. However, because the dprx_work item is designed to requeue itself until a specific timeout expires or an active connection is established, it does not terminate immediately upon being flushed. Consequently, the work queue flush returns prematurely, allowing the domain structure to be freed while the kernel thread associated with that work item still holds references to it.
This race condition leads to use-after-free vulnerabilities and potential system instability. Once the dprx_work callback eventually executes after the timeout period has elapsed or under specific timing conditions, it attempts to interact with a domain object that no longer exists in memory. This results in undefined behavior, which can manifest as kernel panics, data corruption, or silent failures depending on how the freed memory is subsequently utilized by other subsystems. Furthermore, this lingering reference prevents proper unbinding processes from completing efficiently. The completion mechanism waiting for the domain to disappear will block indefinitely until the timeout passes, delaying driver detachment and potentially causing resource leaks that degrade system performance over time.
From a classification perspective, this vulnerability aligns with CWE-416, Use After Free, as it involves accessing memory after it has been freed due to improper lifecycle management of kernel objects. It also relates to CWE-362, Concurrent Execution Using Shared Resource with Improper Synchronization, given the race condition between domain teardown and workqueue execution. In terms of MITRE ATT&CK mapping, this represents a technical weakness that could potentially be leveraged for Denial of Service (DoS) attacks by triggering rapid device removal cycles to exhaust system resources or crash the kernel, falling under techniques such as T1499 Endpoint Denial of Service if exploited maliciously.
The resolution involves modifying the tb_stop function to explicitly tear down DP tunnels that are not yet active in addition to those already established. By canceling these pending work items during the stop phase, the driver ensures that no kernel threads retain references to a domain structure that is being dismantled. This change guarantees that flush_workqueue waits for all relevant tasks to complete before proceeding with resource deallocation. Importantly, this fix preserves functionality for displays that are already live and actively transmitting data, ensuring that normal operation remains unaffected while eliminating the race condition during shutdown or device removal events.
To mitigate similar issues in broader systems administration contexts, it is advisable to ensure that kernel updates containing these fixes are applied promptly. For administrators managing Thunderbolt devices, avoiding rapid hot-plug cycles of display peripherals can reduce exposure to timing-dependent bugs until patches are deployed. Additionally, monitoring system logs for warnings related to workqueue flushes or thunderbolt driver errors can help identify instances where this race condition may have occurred in older kernel versions before the patch was applied.