CVE-2026-74575

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