CVE-2026-98694

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 tb cfg request sync+0x240/0x250 [thunderbolt] Read of size 24 at addr ffff88811067f290 by task kworker/u40:2/1760 tb cfg request sync+0x240/0x250 [thunderbolt] tb cfg read raw+0x367/0x510 [thunderbolt] tb cfg read+0xec/0x240 [thunderbolt] tb port get link generation+0x258/0x420 [thunderbolt] tb usb3 consumed bandwidth+0x1c1/0x2c0 [thunderbolt] tb tunnel consumed bandwidth+0xfd/0x910 [thunderbolt] tb available bandwidth+0x5f2/0xeb0 [thunderbolt] tb recalc estimated bandwidth+0x2a0/0x1bc0 [thunderbolt] tb handle dp bandwidth request+0x1897/0x5e20 [thunderbolt] process one work+0x675/0x1230 worker thread+0x5e6/0xf70 kthread+0x365/0x470 ret from fork+0x54d/0x710 ret from fork asm+0x1a/0x30

Allocated by task 1760: kmalloc cache noprof+0x1ee/0x550 tb cfg read raw+0x1d3/0x510 [thunderbolt] tb cfg read+0xec/0x240 [thunderbolt] tb port get link generation+0x258/0x420 [thunderbolt] tb usb3 consumed bandwidth+0x1c1/0x2c0 [thunderbolt] tb tunnel consumed bandwidth+0xfd/0x910 [thunderbolt] tb available bandwidth+0x5f2/0xeb0 [thunderbolt] tb recalc estimated bandwidth+0x2a0/0x1bc0 [thunderbolt] tb handle dp bandwidth request+0x1897/0x5e20 [thunderbolt] process one work+0x675/0x1230 worker thread+0x5e6/0xf70 kthread+0x365/0x470 ret from fork+0x54d/0x710 ret from fork asm+0x1a/0x30

Freed by task 926: kfree+0x18f/0x4a0 tb cfg request put+0xb7/0xe0 [thunderbolt] tb cfg request work+0x82/0x120 [thunderbolt] process one work+0x675/0x1230 worker thread+0x5e6/0xf70 kthread+0x365/0x470 ret from fork+0x54d/0x710 ret from fork asm+0x1a/0x30

Second to last potentially related work creation: queue work+0x575/0xd00 queue work on+0x77/0x80 tb cfg request cancel+0xc7/0x260 [thunderbolt] tb cfg request sync+0x1f6/0x250 [thunderbolt] tb cfg read raw+0x367/0x510 [thunderbolt] tb cfg read+0xec/0x240 [thunderbolt] tb port get link generation+0x258/0x420 [thunderbolt] tb usb3 consumed bandwidth+0x1c1/0x2c0 [thunderbolt] tb tunnel consumed bandwidth+0xfd/0x910 [thunderbolt] tb available bandwidth+0x5f2/0xeb0 [thunderbolt] tb recalc estimated bandwidth+0x2a0/0x1bc0 [thunderbolt] tb handle dp bandwidth request+0x1897/0x5e20 [thunderbolt] process one work+0x675/0x1230 worker thread+0x5e6/0xf70 kthread+0x365/0x470 ret from fork+0x54d/0x710 ret from fork asm+0x1a/0x30

The last stack trace is helpful because it shows that we are cancelling a request and looking at tb cfg request cancel() what might happen is that tb cfg request work() completes right before tb cfg request cancel() starts and because of this it will call schedule work() queueing the same work to run again. However, it is already removed from the request queue and reference count is dropped so when tb cfg request work() 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 tb cfg request find() or scheduled to run. Then instead of relying on the worker to clean up the request we will do it in tb cfg request cancel() after the work is canceled from running. Make tb cfg request dequeue() release the request only if it was actually removed from the queue.