Description

In the Linux kernel, the following vulnerability has been resolved: thunderbolt: Prevent XDomain delayed work use-after-free on disconnect tb_xdp_handle_request() runs on system_wq and queues xd->state_work via queue_delayed_work() in three request handlers: PROPERTIES_CHANGED_REQUEST, UUID_REQUEST (via start_handshake), and LINK_STATE_CHANGE_REQUEST. Similarly, update_xdomain() queues xd->properties_changed_work when local properties change. Concurrently, tb_xdomain_remove() calls stop_handshake() which does cancel_delayed_work_sync() on both delayed works. Later, tb_xdomain_unregister() calls device_unregister() which eventually frees the xdomain. Since commit 559c1e1e0134 ("thunderbolt: Run tb_xdp_handle_request() in system workqueue") moved the request handler off tb->wq, the handler and the remove path are no longer serialized. If queue_delayed_work() executes after cancel_delayed_work_sync() but before the xdomain is freed, the delayed work fires on a freed object. Add xd->removing that tb_xdomain_remove() sets under xd->lock before calling stop_handshake(). Each external queue site holds the same lock and checks removing before calling queue_delayed_work(). This provides the mutual exclusion needed: either the queue site acquires the lock first and queues work that the subsequent cancel will see, or the remove path acquires the lock first and the queue site observes removing == true and skips the queue.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "8.8",
  "pubDate": "2026-08-15T13:18:03.173Z",
  "pubdate": "2026-08-15T13:18:03.173Z",
  "executiveSummary": "A use-after-free vulnerability exists in the Linux kernel thunderbolt subsystem affecting the XDomain functionality.\nThe vulnerability allows a race condition during the disconnection phase of an XDomain device, leading to a potential use-after-free scenario when delayed work functions execute on a freed object.\nThe affected product is the Linux kernel, specifically concerning the thunderbolt subsystem and XDomain request handling.\nRisk implications include potential denial of service or arbitrary code execution within the kernel context if an attacker can trigger the race condition reliably.\nAttacker capabilities involve local or physical interaction depending on thunderbolt hardware access to induce device disconnection and asynchronous request handling.\nExploitation requires concurrent execution of request handlers and device removal sequences where work is queued after cancellation synchronization.",
  "technicalDetails": "The root cause of the vulnerability stems from a lack of serialization between asynchronous XDomain request handlers running on the system workqueue and the device removal path.\nSpecifically, tb_xdp_handle_request() runs on system_wq and queues xd->state_work via queue_delayed_work() across multiple request handlers including PROPERTIES_CHANGED_REQUEST, UUID_REQUEST via start_handshake, and LINK_STATE_CHANGE_REQUEST.\nSimilarly, update_xdomain() queues xd->properties_changed_work upon local property modifications.\nConcurrently, tb_xdomain_unregister() calls device_unregister() which eventually frees the xdomain object after tb_xdomain_remove() invokes stop_handshake() to execute cancel_delayed_work_sync() on the delayed works.\nCommit 559c1e1e0134 ('thunderbolt: Run tb_xdp_handle_request() in system workqueue') moved the request handler off the dedicated tb->wq, breaking the previous serialization with the removal path.\nIf queue_delayed_work() is invoked after cancel_delayed_work_sync() has completed but before the xdomain object is completely freed, the delayed work executes against a deallocated memory region, resulting in a use-after-free condition.\nThe attack flow relies on triggering asynchronous XDomain requests concurrently with device disconnection or removal.\nWhen the race condition is won by the queuing mechanism post-cancellation, the workqueue subsystem executes the callback function against the dangling pointer of the freed xdomain structure.\nPrivilege and authentication requirements depend on the local system context and physical access to thunderbolt ports capable of establishing XDomain connections.\nThe vulnerable components include tb_xdp_handle_request(), update_xdomain(), tb_xdomain_remove(), and related asynchronous workqueue management functions within the thunderbolt subsystem."
}