CVE-2025-40002

CVE-2025-40002

published October 18, 2025

CVSS
—
EPSS
0%
Percentile
15.8
In the wild
Unconfirmed
What it is

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.

The record
Technical detail
CVSS
Not scored
CVSS v4.0
Not supplied
EPSS
0.00253 · 15.8th percentile
Published
2025-10-18T12:15Z
References (2)
EPSS history
Timeline
  • 18 OCT 08:03Z
    thunderbolt: Fix use-after-free in tb_dp_dprx_work
    cvelistv5