CVE-2026-68370 in Linux
Summary
by MITRE • 08/10/2026
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 caller's 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 request's 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.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 08/10/2026
This vulnerability exists within the Linux kernel's USB gadget framework, specifically in the dummy_hcd driver implementation that emulates a USB host controller for testing purposes. The issue stems from improper synchronization mechanisms when handling shared USB request objects in a multi-threaded environment where concurrent CPU operations can lead to race conditions and memory corruption.
The technical flaw manifests through the misuse of a single shared usb_request object named fifo_req within the dummy_hcd implementation. The driver employs an optimization strategy that reuses this shared request structure for small IN transfers via a fast-path mechanism in the dummy_queue() function. This approach copies caller-provided request data into the shared fifo_req structure and relies on checking list_empty(&fifo_req.queue) to determine if the slot is available for reuse. However, this simplistic approach fails to account for proper atomicity during the complete request lifecycle.
During normal operation, when a USB transfer completes, the system follows standard completion patterns where list_del_init(&req->queue) removes the request from its queue and releases the lock before invoking usb_gadget_giveback_request(). This callback subsequently calls the original request's completion function. The vulnerability occurs because list_del_init() makes the fifo_req.queue appear empty before the completion callback finishes executing, creating a window where another CPU core can simultaneously access the same shared request object and overwrite its completion pointer during the callback execution.
This race condition fundamentally violates memory safety principles and results in undefined behavior when the corrupted completion function pointer is dereferenced. The system experiences general protection faults or page faults within the dummy_timer function as it attempts to execute code at an invalid memory address. The corruption occurs through a legitimate in-bounds memcpy operation on a live shared object, making it particularly difficult to detect since kernel memory sanitizers like KASAN cannot identify this type of memory corruption.
The fix implements a fifo_req_busy bit flag that properly tracks the shared request's entire lifecycle from allocation to completion. This approach transforms the existing list_empty() check into a more robust atomic operation by setting the busy flag when dummy_queue() takes ownership of fifo_req, thereby preventing reuse until the operation completes. The solution also introduces a dedicated dummy_giveback() helper function that ensures consistent cleanup across all four gadget request giveback code paths, effectively eliminating the race condition by maintaining proper synchronization boundaries throughout the shared resource lifetime.
This vulnerability aligns with CWE-362: Concurrent Execution Using Shared Resource with Improper Synchronization and relates to ATT&CK technique T1059.008: Command and Scripting Interpreter: Python within the context of kernel-level memory corruption attacks. The fix demonstrates proper kernel programming practices for shared resource management in concurrent environments, following established patterns for atomic flag manipulation and proper lifecycle management of shared objects.