CVE-2025-40002: thunderbolt: Fix use-after-free in tb_dp_dprx_work

Published Oct 18, 2025
·
Updated

In the Linux kernel, the following vulnerability has been resolved:

thunderbolt: Fix use-after-free in tbdpdprxwork

The original code relies on canceldelayedwork() in tbdpdprxstop(), which does not ensure that the delayed work item tunnel->dprxwork has fully completed if it was already running. This leads to use-after-free scenarios where tbtunnel is deallocated by tbtunnelput(), while tunnel->dprxwork remains active and attempts to dereference tbtunnel in tbdpdprxwork().

A typical race condition is illustrated below:

CPU 0 | CPU 1 tbdptunnelactive() | tbdeactivateandfreetunnel()| tbdpdprxstart() tbtunneldeactivate() | queuedelayedwork() tbdpactivate() | tbdpdprxstop() | tbdpdprxwork() //delayed worker canceldelayedwork() | tbtunnelput(tunnel); | | tunnel = containerof(...); //UAF | tunnel-> //UAF

Replacing canceldelayedwork() with canceldelayedworksync() is not feasible as it would introduce a deadlock: both tbdpdprxwork() and the cleanup path acquire tb->lock, and canceldelayedworksync() would wait indefinitely for the work item that cannot proceed.

Instead, implement proper reference counting: - If canceldelayedwork() 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 tbtunnel remains valid during work item execution while preventing memory leaks.

This bug was found by static analysis.

Affected Software

1 affected component
Linux Linux kernel

Remediation

Recommended actions to resolve this vulnerability, in priority order.

  1. Compensating control

    In the Thunderbolt DisplayPort DPrx cleanup path, implement proper reference counting so tb_tunnel remains valid during tb_dp_dprx_work execution: have the cleanup path acquire tb->lock and call cancel_delayed_work_sync(), and release the tunnel reference from the delayed-work function itself. Do not directly replace cancel_delayed_work() in tb_dp_dprx_stop() if that would introduce the described deadlock.

Event History

Oct 18, 2025
CVE Published
via MITRE·08:03 AM
Data Sourced
via MITRE·08:03 AM
Description
Data Sourced
via NVD·08:15 AM
Description

Frequently Asked Questions

1

What is the severity of CVE-2025-40002?

CVE-2025-40002 is classified as a medium severity vulnerability in the Linux kernel.

2

How do I fix CVE-2025-40002?

To fix CVE-2025-40002, upgrade to the latest stable version of the Linux kernel where the vulnerability has been addressed.

3

What systems are impacted by CVE-2025-40002?

CVE-2025-40002 affects systems running vulnerable versions of the Linux kernel that utilize Thunderbolt technology.

4

What type of vulnerability is CVE-2025-40002?

CVE-2025-40002 is a use-after-free vulnerability that can potentially lead to system instability or a denial of service.

5

Are there any workarounds for CVE-2025-40002?

Currently, the recommended approach is to apply the available kernel patches rather than relying on workarounds.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203