UBUNTU-CVE-2025-40002
In the Linux kernel, the following vulnerability has been resolved: thunderbolt: Fix use-after-free in tb_dp_dprx_work The original code relies on cancel_delayed_work() in tb_dp_dprx_stop(), which does not ensure that the delayed work item tunnel->dprx_work has fully completed if it was already running. This leads to use-after-free scenarios where tb_tunnel is deallocated by tb_tunnel_put(), while tunnel->dprx_work remains active and attempts to dereference tb_tunnel in tb_dp_dprx_work(). A typical race condition is illustrated below: CPU 0 | CPU 1 tb_dp_tunnel_active() | tb_deactivate_and_free_tunnel()| tb_dp_dprx_start() tb_tunnel_deactivate() | queue_delayed_work() tb_dp_activate() | tb_dp_dprx_stop() | tb_dp_dprx_work() //delayed worker cancel_delayed_work() | tb_tunnel_put(tunnel); | | tunnel = container_of(...); //UAF | tunnel-> //UAF Replacing cancel_delayed_work() with cancel_delayed_work_sync() is not feasible as it would introduce a deadlock: both tb_dp_dprx_work() and the cleanup path acquire tb->lock, and cancel_delayed_work_sync() would wait indefinitely for the work item that cannot proceed. Instead, implement proper reference counting: - If cancel_delayed_work() returns true (work is pending), we release the reference in the stop function. - If it returns false (work is executing or already completed), the reference is released in delayed work function itself. This ensures the tb_tunnel remains valid during work item execution while preventing memory leaks. This bug was found by static analysis.
02 / AFFECTED SOFTWARE
Affected packages
11 explicit affected versions
50 explicit affected versions
6 explicit affected versions
12 explicit affected versions
19 explicit affected versions
10 explicit affected versions
6 explicit affected versions
24 explicit affected versions
10 explicit affected versions
26 explicit affected versions
7 explicit affected versions
13 explicit affected versions
35 explicit affected versions
18 explicit affected versions
13 explicit affected versions
4 explicit affected versions
23 explicit affected versions
1 explicit affected versions
21 explicit affected versions
16 explicit affected versions
10 explicit affected versions
12 explicit affected versions
8 explicit affected versions
7 explicit affected versions
12 explicit affected versions
11 explicit affected versions
7 explicit affected versions
12 explicit affected versions
14 explicit affected versions
10 explicit affected versions
1 explicit affected versions
7 explicit affected versions
12 explicit affected versions
1 explicit affected versions
12 explicit affected versions
16 explicit affected versions
9 explicit affected versions
10 explicit affected versions
37 explicit affected versions
1 explicit affected versions
13 explicit affected versions
3 explicit affected versions
10 explicit affected versions
11 explicit affected versions
26 explicit affected versions
13 explicit affected versions
29 explicit affected versions
13 explicit affected versions
12 explicit affected versions
33 explicit affected versions
23 explicit affected versions
10 explicit affected versions
11 explicit affected versions
5 explicit affected versions
12 explicit affected versions
1 explicit affected versions
7 explicit affected versions
12 explicit affected versions
8 explicit affected versions
5 explicit affected versions
10 explicit affected versions
26 explicit affected versions
11 explicit affected versions
1 explicit affected versions
13 explicit affected versions
16 explicit affected versions
3 explicit affected versions
7 explicit affected versions
7 explicit affected versions
51 explicit affected versions
8 explicit affected versions
18 explicit affected versions
12 explicit affected versions
1 explicit affected versions
27 explicit affected versions
8 explicit affected versions
5 explicit affected versions
8 explicit affected versions
10 explicit affected versions
7 explicit affected versions
13 explicit affected versions
13 explicit affected versions
7 explicit affected versions
10 explicit affected versions
12 explicit affected versions
9 explicit affected versions
44 explicit affected versions
16 explicit affected versions
3 explicit affected versions
13 explicit affected versions
26 explicit affected versions
45 explicit affected versions
37 explicit affected versions
14 explicit affected versions
38 explicit affected versions
9 explicit affected versions
9 explicit affected versions
11 explicit affected versions
6 explicit affected versions
7 explicit affected versions
4 explicit affected versions
1 explicit affected versions
13 explicit affected versions
43 explicit affected versions
6 explicit affected versions
10 explicit affected versions
8 explicit affected versions
14 explicit affected versions
4 explicit affected versions
78 explicit affected versions
6 explicit affected versions
11 explicit affected versions
1 explicit affected versions
03 / CONNECTIONS
Connected vulnerabilities
04 / EVIDENCE
Source records
In the Linux kernel, the following vulnerability has been resolved: thunderbolt: Fix use-after-free in tb_dp_dprx_work The original code relies on cancel_delayed_work() in tb_dp_dprx_stop(), which does not ensure that the delayed work item tunnel->dprx_work has fully completed if it was already running. This leads to use-after-free scenarios where tb_tunnel is deallocated by tb_tunnel_put(), while tunnel->dprx_work remains active and attempts to dereference tb_tunnel in tb_dp_dprx_work(). A typical race condition is illustrated below: CPU 0 | CPU 1 tb_dp_tunnel_active() | tb_deactivate_and_free_tunnel()| tb_dp_dprx_start() tb_tunnel_deactivate() | queue_delayed_work() tb_dp_activate() | tb_dp_dprx_stop() | tb_dp_dprx_work() //delayed worker cancel_delayed_work() | tb_tunnel_put(tunnel); | | tunnel = container_of(...); //UAF | tunnel-> //UAF Replacing cancel_delayed_work() with cancel_delayed_work_sync() is not feasible as it would introduce a deadlock: both tb_dp_dprx_work() and the cleanup path acquire tb->lock, and cancel_delayed_work_sync() would wait indefinitely for the work item that cannot proceed. Instead, implement proper reference counting: - If cancel_delayed_work() returns true (work is pending), we release the reference in the stop function. - If it returns false (work is executing or already completed), the reference is released in delayed work function itself. This ensures the tb_tunnel remains valid during work item execution while preventing memory leaks. This bug was found by static analysis.
05 / REFERENCES
Further evidence
- https://git.kernel.org/linus/67600ccfc4f38ebd331b9332ac94717bfbc87ea7
- https://git.kernel.org/stable/c/67600ccfc4f38ebd331b9332ac94717bfbc87ea7
- https://git.kernel.org/stable/c/c07923f6a8729fc27ee652221a51702ff6654097
- https://ubuntu.com/security/CVE-2025-40002
- https://ubuntu.com/security/notices/USN-8029-1
- https://ubuntu.com/security/notices/USN-8029-2
- https://ubuntu.com/security/notices/USN-8029-3
- https://ubuntu.com/security/notices/USN-8030-1
- https://ubuntu.com/security/notices/USN-8048-1
- https://www.cve.org/CVERecord?id=CVE-2025-40002