CVE-2025-40002
Description
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.
AI Insight
LLM-synthesized narrative grounded in this CVE's description and references.
Use-after-free in Linux kernel's Thunderbolt driver due to unsafe delayed work cancellation in tb_dp_dprx_dprx_work.
Vulnerability
A use-after-free bug exists in the Linux kernel's Thunderbolt driver within the function tb_dp_dprx_work. The issue occurs because tb_dp_dprx_stop() uses cancel_delayed_work() to stop a delayed work item, but this does not wait for the work for a work that is already running. When the tunnel is deallocated by tb_tunnel_put() while the delayed work item tunnel->dprx_work is still active, a use-after-free situation arises as the work item attempts to access the freed tb_tunnel structure [1][2].
Exploitation
An attacker needs local access to trigger the race condition. The attack surface involves the Thunderbolt DP (DisplayPort) tunnel lifecycle, specifically during tunnel activation and deactivation sequences. No authentication is required beyond typical user access to trigger sysfs or driver operations. The race is between tb_dp_tunnel_active() on one CPU and tb_dp_dprx_work() execution on another CPU, leading to dereferencing of a freed pointer [1][2].
Impact
Successful exploitation results in use-after-free, which can lead to memory corruption, system crash (denial of service), or potentially arbitrary code execution in kernel context. The attacker gains the ability to corrupt kernel memory, posing a high integrity and availability risk [1][2].
Mitigation
The fix replaces the unsafe pattern with proper reference counting. Instead of trying to cancel the work synchronously (which would deadlock because both the work and the cleanup path acquire tb->lock), the patch ensures that the reference to the tunnel is released either in the stop function (if work was pending) or in the cancel) or in the delayed work function itself (if work was already executing). This maintains tunnel validity during work execution and prevents use-after-free. The fix is included in commit referenced [1] for stable kernels. Users are advised to apply the latest kernel updates to address this vulnerability [2].
AI Insight generated on May 19, 2026. Synthesized from this CVE's description and the cited reference URLs; citations are validated against the source bundle.
Affected products
2Patches
2c07923f6a87267600ccfc4f3Vulnerability mechanics
Generated on May 9, 2026. Inputs: CWE entries + fix-commit diffs from this CVE's patches. Citations validated against bundle.
References
2News mentions
0No linked articles in our index yet.