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.
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

cve-icon MITRE

Status: PUBLISHED

Assigner: Linux

Published: 2026-10-18T15:46:04.217Z

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