CVE-2026-98694: thunderbolt: Fix KASAN reported use-after-free when request is canceled
In the Linux kernel, the following vulnerability has been resolved:
thunderbolt: Fix KASAN reported use-after-free when request is canceled
Alan reported that when doing stress testing sometimes KASAN notices use-after-free during control channel operation (stripped down keeping the relevant parts):
BUG: KASAN: slab-use-after-free in tbcfgrequestsync+0x240/0x250 [thunderbolt] Read of size 24 at addr ffff88811067f290 by task kworker/u40:2/1760 <TASK> tbcfgrequestsync+0x240/0x250 [thunderbolt] tbcfgreadraw+0x367/0x510 [thunderbolt] tbcfgread+0xec/0x240 [thunderbolt] tbportgetlinkgeneration+0x258/0x420 [thunderbolt] tbusb3consumedbandwidth+0x1c1/0x2c0 [thunderbolt] tbtunnelconsumedbandwidth+0xfd/0x910 [thunderbolt] tbavailablebandwidth+0x5f2/0xeb0 [thunderbolt] tbrecalcestimatedbandwidth+0x2a0/0x1bc0 [thunderbolt] tbhandledpbandwidthrequest+0x1897/0x5e20 [thunderbolt] processonework+0x675/0x1230 workerthread+0x5e6/0xf70 kthread+0x365/0x470 retfromfork+0x54d/0x710 retfromforkasm+0x1a/0x30 </TASK>
Allocated by task 1760: kmalloccachenoprof+0x1ee/0x550 tbcfgreadraw+0x1d3/0x510 [thunderbolt] tbcfgread+0xec/0x240 [thunderbolt] tbportgetlinkgeneration+0x258/0x420 [thunderbolt] tbusb3consumedbandwidth+0x1c1/0x2c0 [thunderbolt] tbtunnelconsumedbandwidth+0xfd/0x910 [thunderbolt] tbavailablebandwidth+0x5f2/0xeb0 [thunderbolt] tbrecalcestimatedbandwidth+0x2a0/0x1bc0 [thunderbolt] tbhandledpbandwidthrequest+0x1897/0x5e20 [thunderbolt] processonework+0x675/0x1230 workerthread+0x5e6/0xf70 kthread+0x365/0x470 retfromfork+0x54d/0x710 retfromforkasm+0x1a/0x30
Freed by task 926: kfree+0x18f/0x4a0 tbcfgrequestput+0xb7/0xe0 [thunderbolt] tbcfgrequestwork+0x82/0x120 [thunderbolt] processonework+0x675/0x1230 workerthread+0x5e6/0xf70 kthread+0x365/0x470 retfromfork+0x54d/0x710 retfromforkasm+0x1a/0x30
Second to last potentially related work creation: queuework+0x575/0xd00 queueworkon+0x77/0x80 tbcfgrequestcancel+0xc7/0x260 [thunderbolt] tbcfgrequestsync+0x1f6/0x250 [thunderbolt] tbcfgreadraw+0x367/0x510 [thunderbolt] tbcfgread+0xec/0x240 [thunderbolt] tbportgetlinkgeneration+0x258/0x420 [thunderbolt] tbusb3consumedbandwidth+0x1c1/0x2c0 [thunderbolt] tbtunnelconsumedbandwidth+0xfd/0x910 [thunderbolt] tbavailablebandwidth+0x5f2/0xeb0 [thunderbolt] tbrecalcestimatedbandwidth+0x2a0/0x1bc0 [thunderbolt] tbhandledpbandwidthrequest+0x1897/0x5e20 [thunderbolt] processonework+0x675/0x1230 workerthread+0x5e6/0xf70 kthread+0x365/0x470 retfromfork+0x54d/0x710 retfromforkasm+0x1a/0x30
The last stack trace is helpful because it shows that we are cancelling a request and looking at tbcfgrequestcancel() what might happen is that tbcfgrequestwork() completes right before tbcfgrequestcancel() starts and because of this it will call schedulework() queueing the same work to run again. However, it is already removed from the requestqueue and reference count is dropped so when tbcfgrequestwork() triggers again it will access memory that is already released.
Fix this so that we first make sure a cancelled request is not handed away from tbcfgrequestfind() or scheduled to run. Then instead of relying on the worker to clean up the request we will do it in tbcfgrequestcancel() after the work is canceled from running. Make tbcfgrequestdequeue() release the request only if it was actually removed from the queue.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
debian/linuxto a version that resolves this vulnerability.Fixed in 6.12.113-1 - Upgrade
Upgrade
debian/linuxto a version that resolves this vulnerability.Fixed in 7.2.10-1 - Upgrade
Upgrade
debian/linux-6.12to a version that resolves this vulnerability.Fixed in 6.12.113-1~deb12u1 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 5.10.273 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 5.15.224 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 6.1.191 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 6.6.160 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 6.12.113 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 6.18.56 - 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.12.115-2Fixed in 7.2.12-1Fixed in 7.2.15-1 - Compensating control
Update the Thunderbolt control-channel request cancellation logic so cancelled requests are not returned by tb_cfg_request_find() or scheduled to run; make tb_cfg_request_dequeue() release a request only when it actually removes it from the request_queue, and have tb_cfg_request_cancel() release the request after canceling its work instead of relying on tb_cfg_request_work() for cleanup.
Event History
Frequently Asked Questions
What conditions are associated with triggering this issue?
The reported use-after-free occurred during stress testing while performing Thunderbolt control-channel operations. The stack trace shows it in work handling a DisplayPort bandwidth request and subsequent bandwidth recalculation.
How can I identify whether a system is encountering this vulnerability?
A KASAN-enabled kernel may report a slab-use-after-free in tb_cfg_request_sync in the thunderbolt module. The report can include calls such as tb_cfg_read_raw, tb_port_get_link_generation, tb_handle_dp_bandwidth_request, and a kworker task.
Is there a known mitigation if updating is not immediately possible?
The provided information does not identify a workaround. Reducing or avoiding the Thunderbolt control-channel and DisplayPort bandwidth-change activity associated with the reported trigger may reduce exposure, but this is not documented as a complete mitigation.