CVE-2025-40002

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> thunderbolt: Fix use-after-free in tb_dp_dprx_work<br /> <br /> The original code relies on cancel_delayed_work() in tb_dp_dprx_stop(),<br /> which does not ensure that the delayed work item tunnel-&gt;dprx_work has<br /> fully completed if it was already running. This leads to use-after-free<br /> scenarios where tb_tunnel is deallocated by tb_tunnel_put(), while<br /> tunnel-&gt;dprx_work remains active and attempts to dereference tb_tunnel<br /> in tb_dp_dprx_work().<br /> <br /> A typical race condition is illustrated below:<br /> <br /> CPU 0 | CPU 1<br /> tb_dp_tunnel_active() |<br /> tb_deactivate_and_free_tunnel()| tb_dp_dprx_start()<br /> tb_tunnel_deactivate() | queue_delayed_work()<br /> tb_dp_activate() |<br /> tb_dp_dprx_stop() | tb_dp_dprx_work() //delayed worker<br /> cancel_delayed_work() |<br /> tb_tunnel_put(tunnel); |<br /> | tunnel = container_of(...); //UAF<br /> | tunnel-&gt; //UAF<br /> <br /> Replacing cancel_delayed_work() with cancel_delayed_work_sync() is<br /> not feasible as it would introduce a deadlock: both tb_dp_dprx_work()<br /> and the cleanup path acquire tb-&gt;lock, and cancel_delayed_work_sync()<br /> would wait indefinitely for the work item that cannot proceed.<br /> <br /> Instead, implement proper reference counting:<br /> - If cancel_delayed_work() returns true (work is pending), we release<br /> the reference in the stop function.<br /> - If it returns false (work is executing or already completed), the<br /> reference is released in delayed work function itself.<br /> <br /> This ensures the tb_tunnel remains valid during work item execution<br /> while preventing memory leaks.<br /> <br /> This bug was found by static analysis.