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.
- Compensating control
Update the Thunderbolt control-channel request cancellation logic so tb_cfg_request_dequeue() releases a request only when it was actually removed from request_queue, preventing a cancelled request from being handed to tb_cfg_request_work() or scheduled to run again after it has been freed.