VYPR
Unrated severityNVD Advisory· Published Oct 18, 2025· Updated Apr 15, 2026

CVE-2025-40002

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

2
  • Linux/Kernelinferred2 versions
    (expand)+ 1 more
    • (no CPE)
    • (no CPE)

Patches

2

Vulnerability mechanics

Generated on May 9, 2026. Inputs: CWE entries + fix-commit diffs from this CVE's patches. Citations validated against bundle.

References

2

News mentions

0

No linked articles in our index yet.