Bug 2555146 (CVE-2026-98691)

Summary:	CVE-2026-98691 kernel: thunderbolt: Tear down inactive DP tunnels when the domain is stopped
Product:	[Other] Security Response	Reporter:	OSIDB Bzimport <bzimport>
Component:	vulnerability	Assignee:	Product Security DevOps Team <prodsec-dev>
Status:	NEW ---	QA Contact:
Severity:	low	Docs Contact:
Priority:	low
Version:	unspecified	CC:	akhatavk, aos-team-art-private, asdas, dpaolell, jdelft, jupierce, lgarciaa, mbiarnes, ppalepu, ppostler, prdhamdh, rhel-process-autobot, sghai, sidsharm, suppawar, vlaad, watson-tool-maintainers
Target Milestone:	---	Keywords:	Security
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	---
Doc Text:	A flaw was found in the Linux kernel's Thunderbolt subsystem. This vulnerability can lead to a Denial of Service (DoS) or system instability when a Thunderbolt device is disconnected or unbound. When a Thunderbolt domain is stopped, inactive DisplayPort (DP) tunnels are not properly torn down, allowing scheduled background tasks to continue running after the domain has been dismantled. A local privileged user or physically present attacker can trigger this flaw by unbinding or disconnecting a device during DisplayPort tunnel initialization, causing the domain removal process to hang or execute callbacks against torn-down resources.	Story Points:	---
Clone Of:		Environment:
Last Closed:		Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description OSIDB Bzimport 2026-10-18 15:57:01 UTC

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

thunderbolt: Tear down inactive DP tunnels when the domain is stopped

tb_stop() only tears down DMA tunnels so a DP tunnel that is still
waiting for dprx_work to complete keeps that work queued while the
routers are removed and the control channel is stopped. The work only
stops once the DPRX timeout has passed and because it requeues itself
until then the flush_workqueue() in tb_domain_remove() won't wait for its
final run. The callback then runs against a domain that is already torn
down. A reference to that domain is kept so the completion waiting for
that domain to disappear in unbind will block until the timeout is
eventually reached.

Tear down DP tunnels that are not active yet as well which also cancels
that work. Tunnels for displays that are already alive are untouched and
keep working.

Comment 1 Mauro Matteo Cascella 2026-10-22 03:48:49 UTC

Upstream advisory:
https://git.kernel.org/pub/scm/linux/security/vulns.git/plain/cve/published/2026/CVE-2026-98691.mbox