CVE-2026-74575
HighCVSS 8.8Exploitation Probability (EPSS)
Low risk14th percentile - higher than 14% of all known CVEs
Summary
In the Linux kernel, the Thunderbolt subsystem has a use-after-free vulnerability in XDomain delayed work during disconnect. The tb_xdp_handle_request() function may queue delayed work after tb_xdomain_remove() cancels it synchronously but before the xdomain object is freed, leading to work executing on freed memory. The fix adds an xd->removing flag and synchronization via xd->lock.
Risk Assessment
The risk includes potential code execution in kernel context or system crash (panic) due to use-after-free. However, exploitation requires physical access to a Thunderbolt port or the ability to trigger relevant events, limiting exploitability.
Recommendation
Update the Linux kernel to a version containing the fix for this issue. Also, restrict physical access to Thunderbolt ports in sensitive environments.
Original NVD description (English source)
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.