---
id: "CVE-2026-98690"
kind: "vulnerability"
aliases: ["CVE-2026-98690"]
title: "Linux kernel Thunderbolt: leaked domain reference hangs driver unbind"
severity: "low"
cvss: null
epss: null
exploited: false
status: "open"
category: "runtime"
products: []
ecosystems: []
tags: ["kernel", "laptops", "linux", "runtime", "thunderbolt", "usb4"]
not_affected_if: ["no-thunderbolt-hardware", "thunderbolt-driver-not-loaded"]
published_at: "2026-10-18T16:17:22+00:00"
first_seen_at: "2026-10-23T21:57:16+00:00"
updated_at: "2026-10-25T05:19:06+00:00"
sources: [{"source": "nvd", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-98690", "first_seen_at": "2026-10-23T21:57:16+00:00"}]
---

# Linux kernel Thunderbolt: leaked domain reference hangs driver unbind

When a DisplayPort tunnel is torn down before its DPRX read finishes, the Thunderbolt driver leaks a reference to the domain. Unbinding the driver then blocks forever in a completion wait, which hangs the machine's Thunderbolt handling.

_Summary, check and fix written by a model from the sources; labelled as such._

## How to check

- Run `uname -r` and compare against the fixed kernel in the advisory (unknown in the sources)
- Check whether Thunderbolt hardware is present with `lspci | grep -i thunderbolt` or `boltctl list`

## Fix

- Update the Linux kernel to a release that includes the upstream commit fixing the domain reference leak in the thunderbolt driver (fixed version unknown in the sources)

## Timeline

- 2026-10-23T21:57:16+00:00 nvd https://nvd.nist.gov/vuln/detail/CVE-2026-98690

## From the sources

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

thunderbolt: Fix domain reference leak when DPRX read is canceled

tb_tunnel_one_dp() takes a domain reference which is only dropped once
tb_dp_tunnel_active() has run on the work queue. If that work is
cancelled that reference is leaked. Since
commit f5cc545f5969 ("thunderbolt: Wait for tb_domain_release() to
complete when driver is removed") instead of just leaking memory this
now also blocks in the completion wait forever when unbinding the
driver.

This can be triggered whenever a DP tunnel is torn down before the DPRX
read has completed, e.g. by unplugging within the timeout, and then
unbinding the driver.

That reference only exists to keep the domain around while the DPRX work
is scheduled so let the work itself own it: take it in tb_dp_dprx_start()
and drop it in both places that end the work. Get/put are then paired
inside the same file and it doesn't matter anymore if the callback ever
runs.

---

_Free to read at a human pace. An API with keys and an MCP server are in preparation; early access: hello@infrastack.ai_