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

thunderbolt: Don't access a DP tunnel after its DPRX read was canceled

tb_dp_dprx_work() checks ->dprx_canceled before it takes tb->lock so it
misses a tb_dp_dprx_stop() that could not cancel the already running
work. It then polls the DPRX capabilities and runs the callback for a
tunnel that has already been torn down while the domain is suspending or
going away.

This can be hit by cancelling the DPRX read from outside the ordered
tb->wq: During suspend tb_disconnect_and_release_dp() does just this and
with a later patch tb_stop() will do it as well. The latter in combination
with the Apple NHI where the DPRX read never completed is how I hit
this.

Check the flag with tb->lock held instead and check it again in
tb_dp_tunnel_active() because the callback runs after the lock has been
dropped again.

Also clear the flag in tb_dp_dprx_start() so that it only ever describes
the work that is currently in flight.
Published: 2026-10-18
Score: 4.7 Medium
EPSS: < 1% Very Low
KEV: No
Impact: Denial of Service via Kernel Crash
Action: Apply Patch
AI Analysis

Impact

A race condition exists in the Linux kernel Thunderbolt driver. The routine bypasses proper synchronization when checking a cancellation flag, allowing a later cancel operation to unsafely remove a DisplayPort tunnel while work is still pending. After the removal, the driver polls the tunnel’s capabilities and runs a callback for a tunnel that has already been torn down, which can result in the kernel accessing invalid memory. This flaw is rooted in improper locking and concurrent resource cleanup, leading to a use‑after‑free or data corruption scenario that may crash the kernel.

Affected Systems

All Linux kernel builds that ship with the stock Thunderbolt implementation are vulnerable. Every distribution using the default kernel includes this race condition until the patch is applied, affecting any system that relies on Thunderbolt DisplayPort support.

Risk and Exploitability

The EPSS score is < 1% and the vulnerability is not listed in CISA’s KEV catalog, yet the impact of a kernel crash is severe. Based on the description, it is inferred that an attacker with local access to a device connected via Thunderbolt, or one who can force the system to suspend or disconnect the device, could trigger the fault. The race conditions between workqueue callbacks and device removal expose the kernel to use‑after‑free or data corruption, enabling denial of service. The CVSS score of 4.7 indicates moderate severity.

Generated by OpenCVE AI on October 23, 2026 at 06:08 UTC.

Remediation

No solution or workaround provided in the CVE record.

OpenCVE Recommended Actions

  • Update the Linux kernel to the latest stable release that includes the patch for CVE-2026-98689
  • Temporarily disable Thunderbolt DisplayPort support or unplug Thunderbolt devices until a patch becomes available
  • Minimize suspend or hot‑plug events that could trigger DP tunnel teardown while docked devices remain connected

Generated by OpenCVE AI on October 23, 2026 at 06:08 UTC.

Tracking

Sign in to view the affected projects.

Advisories

No advisories yet.

History

Fri, 23 Oct 2026 00:45:00 +0000

Type Values Removed Values Added
Weaknesses CWE-416
CWE-847

Thu, 22 Oct 2026 12:30:00 +0000

Type Values Removed Values Added
Weaknesses CWE-366
References
Metrics threat_severity

None

 cvssV3_1

{'score': 4.7, 'vector': 'CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H'}

threat_severity

Moderate

Sun, 18 Oct 2026 22:45:00 +0000

Type Values Removed Values Added
Weaknesses CWE-416
CWE-847

Sun, 18 Oct 2026 16:00:00 +0000

Type Values Removed Values Added
Description In the Linux kernel, the following vulnerability has been resolved: thunderbolt: Don't access a DP tunnel after its DPRX read was canceled tb_dp_dprx_work() checks ->dprx_canceled before it takes tb->lock so it misses a tb_dp_dprx_stop() that could not cancel the already running work. It then polls the DPRX capabilities and runs the callback for a tunnel that has already been torn down while the domain is suspending or going away. This can be hit by cancelling the DPRX read from outside the ordered tb->wq: During suspend tb_disconnect_and_release_dp() does just this and with a later patch tb_stop() will do it as well. The latter in combination with the Apple NHI where the DPRX read never completed is how I hit this. Check the flag with tb->lock held instead and check it again in tb_dp_tunnel_active() because the callback runs after the lock has been dropped again. Also clear the flag in tb_dp_dprx_start() so that it only ever describes the work that is currently in flight.
Title thunderbolt: Don't access a DP tunnel after its DPRX read was canceled
First Time appeared Linux
Linux linux Kernel
CPEs cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
Vendors & Products Linux
Linux linux Kernel
References

Subscriptions

Linux Linux Kernel
cve-icon MITRE

Status: PUBLISHED

Assigner: Linux

Published:

Updated: 2026-10-19T09:23:59.268Z

Reserved: 2026-09-25T10:25:14.364Z

Link: CVE-2026-98689

cve-icon Vulnrichment

No data.

cve-icon NVD

Status : Received

Published: 2026-10-18T16:17:22.317

Modified: 2026-10-19T10:19:33.283

Link: CVE-2026-98689

cve-icon Redhat

Severity : Moderate

Publid Date: 2026-10-18T00:00:00Z

Links: CVE-2026-98689 - Bugzilla

cve-icon OpenCVE Enrichment

Updated: 2026-10-23T06:15:13Z

Weaknesses
  • CWE-366

    Race Condition within a Thread