In the Linux kernel, the following vulnerability has been resolved:
usb: gadget: dummyhcd: prevent fiforeq reuse during giveback
dummyhcd embeds a single shared usbrequest (dum->fiforeq) that the "emulated single-request FIFO" fast-path in dummyqueue() reuses for small IN transfers: it copies the caller's request into it (req->req = *req) and queues it, treating listempty(&fifo_req.queue) as "the slot is free".
The completion side (dummytimer/transfer/nuke/dummydequeue) follows the standard pattern: listdelinit(&req->queue) unlinks the request, then the lock is dropped and usbgadgetgivebackrequest() invokes req->complete(). But listdelinit() makes fiforeq.queue look empty before the completion callback returns, so a concurrent dummyqueue() on another CPU sees the slot as free, reuses fiforeq and runs req->req = *req -- overwriting req->complete while dummytimer is mid-calling it. The indirect call then jumps to a clobbered pointer, causing a general protection fault / page fault in dummy_timer (syzkaller extid faf3a6cf579fc65591ca). The clobbering write is an in-bounds memcpy on a live shared object, so KASAN cannot flag it.
Add a fiforeqbusy bit covering the shared request's whole lifetime: set it in dummyqueue() when the FIFO fast-path takes fiforeq (making it the fast-path guard, replacing the listempty(&fiforeq.queue) test), and clear it after the completion callback has returned, via a dummy_giveback() helper used at all four gadget-request giveback sites. The shared slot can no longer be reused until its completion callback has finished.
{
"osv_generated_from": "https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/68xxx/CVE-2026-68370.json",
"cna_assigner": "Linux"
}