CVE-2026-68370: usb: gadget: dummy_hcd: prevent fifo_req reuse during giveback

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(&fiforeq.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 dummytimer (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 dummygiveback() helper used at all four gadget-request giveback sites. The shared slot can no longer be reused until its completion callback has finished.