CVE-2026-98688 in Linux
Summary
by MITRE • 10/18/2026
In the Linux kernel, the following vulnerability has been resolved:
thunderbolt: Fix NULL dereference in tb_remove_work()
There is a slight race between tb_remove_work() and tb_domain_remove() which leads to dereferencing a NULL tb->root_switch pointer inside tb_free_unplugged_xdomains():
Thread A Thread B
tb_remove_work() tb_domain_remove() mutex_lock(&tb->lock) tb_stop() /* doesn't cancel a running callback */ cancel_delayed_work(&tcm->remove_work) ... tb_switch_remove(tb->root_switch) tb->root_switch = NULL mutex_unlock(&tb->lock) mutex_lock(&tb->lock) ... /* without checking ->root_switch */ tb_free_unplugged_xdomains(tb->root_switch) mutex_unlock(&tb->lock)
Commit a8937f35cf39 ("thunderbolt: Remove XDomain from the bus without holding tb->lock") doesn't seem right to move tb_free_unplugged_xdomains() out of the &tb->lock section and the check for tb->root_switch, in particular. It states:
For this reason separate removing the XDomain from the topology data structures (where we need the lock) from unregistering the device from the bus (where remove callbacks of the drivers are being called).
tb_free_unplugged_xdomains() belongs to the former group of functions requiring the lock. And it also calls tb_xdomain_remove() which should only be called with &tb->lock held.
Found by Linux Verification Center (linuxtesting.org) with Svace static analysis tool.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 10/18/2026
The Thunderbolt subsystem in the Linux kernel contains a race condition vulnerability within the device removal logic, specifically involving the interaction between tb_remove_work and tb_domain_remove functions. This flaw results in a NULL pointer dereference that can lead to a system crash or denial of service. The root cause lies in an improper synchronization mechanism where critical sections are split across different locking contexts without adequate checks for object validity. Specifically, the function tb_free_unplugged_xdomains attempts to access the tb->root_switch pointer while holding the tb lock, but this operation occurs after another thread has already set that pointer to NULL during domain removal procedures.
The technical flaw manifests through a specific sequence of events involving two concurrent threads operating on Thunderbolt controller data structures. In one execution path, Thread B executes tb_domain_remove which acquires the tb lock and subsequently calls tb_switch_remove. This operation sets the tb->root_switch member to NULL before releasing the mutex. Meanwhile, in another thread, Thread A is executing tb_remove_work. Although it also attempts to acquire the same tb lock, there exists a window where the state of root_switch changes between when Thread B releases its hold on the lock and when Thread A acquires it. Crucially, prior commits attempted to optimize performance by moving certain cleanup operations outside the locked section but failed to account for the fact that tb_free_unplugged_xdomains relies on the presence of a valid root switch pointer. Consequently, when Thread A proceeds to call tb_free_unplugged_xdomains with the now NULL pointer, it triggers an invalid memory access.
This vulnerability is classified under CWE-416 which denotes Use After Free or Incorrect Release Order issues, as well as CWE-362 for Concurrent Execution using Shared Resource without Proper Synchronization. From a threat modeling perspective aligned with MITRE ATT&CK techniques, this represents a potential Denial of Service vector where an attacker could potentially trigger the race condition through rapid device insertion and removal cycles to crash the kernel or destabilize system operations. The impact is primarily localized to systems utilizing Thunderbolt controllers but can result in complete system instability due to the severity of NULL pointer dereferences in core kernel subsystems.
The resolution involves correcting the locking strategy within the thunderbolt driver codebase. Developers must ensure that tb_free_unplugged_xdomains is called only when it is guaranteed that tb->root_switch remains valid, typically by keeping such operations strictly within sections protected by the appropriate mutex locks or adding explicit null checks before dereferencing pointers derived from shared state. Mitigation strategies for system administrators include applying kernel updates provided by distribution vendors as soon as they become available. For environments where immediate patching is not feasible, limiting physical access to Thunderbolt ports and disabling hot-plug capabilities via BIOS settings can reduce the attack surface by preventing unauthorized or rapid device changes that might trigger this race condition.