CVE-2026-98689
Microsoft — thunderbolt: Don't access a DP tunnel after its DPRX read was canceled
Microsoft · Not classified by connected sources
EVRS 0 of 100 Informational
Monitor
Rank 2,932 of 2,960 tracked
Why it scores 0
Evidence available: 2 of 8 signalsNo strong exploitation, disclosure, or severity signal is available for this CVE yet.
- CISA KEVDid not apply
- RansomwareNo data
- Vendor exploitationNo data
- EPSSDid not apply
- Microsoft Exploitability IndexNo data
- Pre-patch disclosureNo data
- KEV recencyNo data
- CVSSNo data
The band answers “how soon”, not “how bad”. No data for: Ransomware, Vendor exploitation, Microsoft Exploitability Index, Pre-patch disclosure, KEV recency, CVSS. Why some signals show no data
Fix
No fixed version identified yetAffected versions
Not identified by the connected sources
Remediation
NVD lists one or more references for this CVE that aren't tagged as a patch or vendor advisory. Review them directly to confirm patch availability and applicability before making a remediation decision.
Evidence
Each value with its source| Measure | Value | Source |
|---|---|---|
| CVSS base scoreHow severe the flaw is in itself. It does not say how likely an attack is. | Not publishedNVD and the CVE record were checked and hold no score. | NVD |
| FIRST EPSSFIRST's estimate of the chance this is exploited in the next 30 days, and how that ranks against all CVEs. | 0.002 (5.5th pctl) | FIRST EPSS |
| Actively exploitedWhether a source of record has confirmed attacks using it in the wild. | Not confirmed | Patch Tuesday |
| Public exploit moduleA module existing is not the same as active exploitation. | None known | Metasploit |
| EUVD cross-referenceENISA's record: CVSS 0.0, assigned by Linux. | Listed | ENISA EUVD |
Description
NVDIn 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.