CVE-2026-98692: thunderbolt: Make the DP tunnel activation callback mandatory
In the Linux kernel, the following vulnerability has been resolved:
thunderbolt: Make the DP tunnel activation callback mandatory
tbtunnelallocdp() takes an optional callback which is run from dprxwork once the DPRX capabilities read has completed. Without that callback tbdpdprxstart() reads the capabilities synchronously and never queues the work. It however always takes a tunnel reference which is only dropped by dprxwork itself or by tbdpdprxstop() when canceldelayedwork() actually canceled that work. That reference is thus leaked for every tunnel without a callback.
The only tunnels without one are those from tbtunneldiscoverdp(), which are activated again when restoring from hibernation. Pass the callback to tbtunneldiscoverdp() as well and drop the synchronous path such that the DPRX capabilities are always read from dprxwork. Hibernation restore then also no longer blocks for up to 12 seconds while waiting for that read to complete.
Also fix up the KUnit tests.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
debian/linuxto a version that resolves this vulnerability.Fixed in 7.2.10-1 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 6.18.61 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 7.2.10 - Upgrade
Upgrade
debian/linuxto a version that resolves this vulnerability.Fixed in 6.1.176-1Fixed in 6.1.190-1Fixed in 6.12.107-1Fixed in 6.12.116-1Fixed in 7.2.15-1Fixed in 7.3.3-1
Event History
Frequently Asked Questions
Which systems are affected by this issue?
The leak affects Linux kernel systems using discovered DisplayPort tunnels that are activated again during hibernation restore. The affected tunnels are those created through tb_tunnel_discover_dp().
Does exploitation require an external attacker?
The provided information describes a kernel reference leak during DisplayPort tunnel handling and hibernation restore; it does not identify attacker-controlled input, privileges, or a remote attack path. It is therefore not possible from the available data to determine an attacker exploitation requirement.
What operational symptom may occur during hibernation restore?
Before the fix, hibernation restore can block for up to 12 seconds while waiting for the DPRX capabilities read to finish. The fix moves this read to dprx_work so that restore no longer waits synchronously.
What change addresses the reference leak?
The fix makes the DP tunnel activation callback mandatory, including for tunnels discovered by tb_tunnel_discover_dp(). This ensures DPRX capabilities are read through dprx_work, which can release the tunnel reference.