CVE-2026-90021 in Linux
Summary
by MITRE • 09/16/2026
In the Linux kernel, the following vulnerability has been resolved:
usb: gadget: f_midi: initialize work in f_midi_alloc()
f_midi_alloc initializes free_ref to 1 and it can only be incremented when a sound card is registered via f_midi_register_card(). f_midi_register_card() is only called in f_midi_bind() which actually performs INIT_WORK. If f_midi_bind() is never run, work is not initialized and the if condition in f_midi_free becomes true, this results in a warning later in __flush_work as work->func = 0. Fix this by moving INIT_WORK from f_midi_bind() to f_midi_alloc().
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 09/16/2026
The Linux kernel vulnerability identified within the USB gadget MIDI function driver stems from an improper initialization sequence of synchronization primitives, specifically a work queue structure. The core technical flaw lies in the placement of the INIT_WORK macro call within the source code logic for the f_midi module. Originally, the initialization of the free_ref counter and the associated work item were separated across different lifecycle functions. Specifically, while f_midi_alloc correctly initializes the reference count to one, the actual initialization of the work structure via INIT_WORK was deferred until f_midi_bind is executed. This architectural decision creates a critical race condition or state inconsistency if the binding phase is bypassed or fails before completion. In scenarios where f_midi_bind is never invoked, the work item remains in an uninitialized state with its function pointer set to zero. When subsequent cleanup routines such as f_midi_free attempt to manage resources based on reference counts that may have changed due to partial registration attempts, they trigger a check that assumes valid initialization. This leads to __flush_work being called on an invalid or null work structure, resulting in kernel warnings and potential instability during device teardown or error handling paths.
From a security and stability perspective, this issue represents a classic case of uninitialized memory usage leading to undefined behavior within the kernel space. Although it may not directly allow for remote code execution in all configurations, it compromises system reliability by triggering kernel warnings that can clutter logs, obscure other critical errors, and potentially lead to denial-of-service conditions if the warning path escalates into a panic or causes resource leaks due to improper cleanup sequences. The vulnerability aligns with CWE-908, which describes the use of uninitialized resources, as well as CWE-665 regarding improper initialization. In terms of attack surface analysis under the MITRE ATT&CK framework for enterprise environments, this type of flaw could be leveraged in local privilege escalation scenarios if an attacker can trigger specific gadget configurations that bypass normal binding procedures, thereby forcing the kernel into a state where it processes malformed or null pointers during resource deallocation. It highlights the importance of ensuring that all synchronization primitives are initialized at the earliest possible point in object allocation to prevent access before initialization errors.
The resolution involves refactoring the f_midi_alloc function to include the INIT_WORK call, thereby guaranteeing that the work structure is properly set up immediately upon memory allocation rather than waiting for a later binding phase. This change ensures that regardless of whether f_midi_bind completes successfully or fails early, the underlying synchronization mechanism remains valid and safe for subsequent operations like flushing or cancellation. By moving this initialization step upstream in the lifecycle, the driver adheres to best practices for resource management where dependencies are resolved at creation time rather than runtime configuration time. This approach minimizes the window of vulnerability and ensures that any code path accessing the work item encounters a fully initialized structure with valid function pointers.
To mitigate similar issues in broader kernel development or system administration contexts, it is essential to enforce strict coding standards regarding initialization order. Developers should ensure that all dynamic resources, including mutexes, spinlocks, and work queues, are initialized concurrently with their allocation. Automated static analysis tools can be configured to detect patterns where INIT_WORK or similar primitives are called in binding functions rather than allocation functions, flagging them as potential risks for use-before-initialization bugs. Furthermore, thorough code review processes should focus on error paths and early exit scenarios to verify that cleanup routines do not assume prior successful execution of setup phases. For system administrators, keeping the Linux kernel updated with patches addressing these internal logic errors is crucial to maintaining overall system integrity and preventing unexpected warnings or crashes during USB gadget operations involving MIDI devices.