In the Linux kernel, the following vulnerability has been resolved:
usb: gadget: dummy_hcd: prevent fifo_req reuse during giveback
dummy_hcd embeds a single shared usb_request (dum->fifo_req) that the emulated single-request FIFO fast-path in dummy_queue() reuses for small IN transfers: it copies the callers request into it (req->req = *_req) and queues it, treating list_empty(&fifo_req.queue) as the slot is free.
The completion side (dummy_timer/transfer/nuke/dummy_dequeue) follows the standard pattern: list_del_init(&req->queue) unlinks the request, then the lock is dropped and usb_gadget_giveback_request() invokes req->complete(). But list_del_init() makes fifo_req.queue look empty before the completion callback returns, so a concurrent dummy_queue() on another CPU sees the slot as free, reuses fifo_req and runs req->req = *_req – overwriting req->complete while dummy_timer 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 fifo_req_busy bit covering the shared requests whole lifetime: set it in dummy_queue() when the FIFO fast-path takes fifo_req (making it the fast-path guard, replacing the list_empty(&fifo_req.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.
References
- https://git.kernel.org/stable/c/67b589d09a96882d56842dced5698ed8dd06ce45
- https://git.kernel.org/stable/c/d5e5cd3654d2b5359a12ea6586120f05b28634ee
- https://git.kernel.org/stable/c/e239ea91b48180ed48a86ac25643832a02c88456
- https://git.kernel.org/stable/c/e24b33618231034bf01dfaff4fd3409d4b4d5b2e
- https://git.kernel.org/stable/c/e2b2740f1242bc70b5b46da2cdbbaa419f490e59