Bug 2555096 (CVE-2026-98689) - CVE-2026-98689 kernel: thunderbolt: Don't access a DP tunnel after its DPRX read was canceled
Summary: CVE-2026-98689 kernel: thunderbolt: Don't access a DP tunnel after its DPRX r...
Keywords:
Status: NEW
Alias: CVE-2026-98689
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Product Security DevOps Team
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2026-10-18 15:54 UTC by OSIDB Bzimport
Modified: 2026-10-22 03:34 UTC (History)
17 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed:
Embargoed:


Attachments (Terms of Use)

Description OSIDB Bzimport 2026-10-18 15:54:11 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.