CVE-2026-90031 in Linux
Summary
by MITRE • 09/17/2026
In the Linux kernel, the following vulnerability has been resolved:
usb-storage: ene_ub6250: fix race between scan work and probe
ene_ub6250_probe() calls usb_stor_probe2(), which starts the usb-storage infrastructure and schedules the delayed scan work. The driver then calls ene_get_card_type(), which sends an ENE command through ene_send_scsi_cmd() and the usb-storage bulk transfer helpers.
Both the delayed scan work, through usb_stor_Bulk_max_lun(), and ene_get_card_type() use us->current_urb. The scan work serializes this access with us->dev_mutex, but the ENE card-type probe does not. If the scan work runs while ene_get_card_type() is still using us->current_urb, usb_submit_urb() warns that the URB is already active.
Serialize ene_get_card_type() with us->dev_mutex, matching the locking used by the scan path.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 09/17/2026
The vulnerability identified in the Linux kernel's USB storage driver for ENE UB6250 devices represents a classic race condition arising from inconsistent synchronization of shared resources during device initialization and scanning phases. The core issue lies in how the ene_ub6250_probe function orchestrates the startup sequence of the usb-storage infrastructure. Upon probing, the system invokes usb_stor_probe2 to initialize the underlying USB storage framework, which subsequently schedules a delayed work item responsible for scanning available logical units on the device. Concurrently, immediately following this initialization, the driver executes ene_get_card_type to determine the specific type of card inserted in the reader by sending an ENE-specific command via ene_send_scsi_cmd and associated bulk transfer helpers. Both the background scan work, specifically through the usb_stor_Bulk_max_lun function, and the synchronous probe routine rely on accessing a shared pointer known as us->current_urb to manage active USB Request Blocks.
The technical flaw stems from an asymmetry in locking mechanisms applied to these two concurrent execution paths. The delayed scan work correctly serializes its access to the current URB by acquiring us->dev_mutex, ensuring that only one thread manipulates the URB state at any given time. However, the ene_get_card_type function, which operates within the probe context before returning control to the kernel's device management subsystem, fails to acquire this same mutex. This omission creates a window of vulnerability where both threads can attempt to submit or manipulate the same USB Request Block simultaneously. When usb_submit_urb is called by either path while the URB is already active and held by the other, the kernel detects this invalid state and triggers a warning, indicating that the driver has violated the expected lifecycle management rules for USB transfers.
From an operational impact perspective, this race condition can lead to several adverse outcomes depending on timing and system load. The immediate manifestation is often a kernel warning or error message in the dmesg log, which may clutter logs and indicate instability. More severely, if the concurrent access leads to memory corruption or undefined behavior within the USB subsystem, it could result in driver crashes, system hangs, or data corruption during card detection operations. Since this occurs during device probing, it affects the reliability of detecting storage media on systems utilizing ENE UB6250 chipsets, potentially causing devices to fail initialization entirely if the race condition consistently triggers a fatal error path rather than just a warning. This undermines the robustness of USB mass storage support in embedded and industrial environments where such hardware is commonly deployed.
To mitigate this vulnerability, the recommended remediation involves synchronizing access to us->current_urb by applying the same locking strategy used by the scan work. Specifically, ene_get_card_type must be modified to acquire us->dev_mutex before initiating any USB commands that interact with current URBs and release it upon completion. This ensures mutual exclusion between the synchronous probe routine and the asynchronous scanning worker thread. By aligning the locking discipline of the ENE-specific card type detection logic with the standard usb-storage infrastructure, the race condition is eliminated. Developers should verify this fix in updated kernel versions or apply backported patches to affected stable releases. Adhering to consistent mutex usage across all code paths that touch shared driver state variables is critical for maintaining stability in complex USB drivers.
This vulnerability aligns with CWE-362, which describes concurrent execution using shared resources with improper synchronization. The lack of mutual exclusion when accessing the URB pointer allows multiple threads to interfere with each other's operations on a single resource without proper coordination. Furthermore, from an offensive security perspective related to ATT&CK techniques, while this is primarily a stability issue rather than a direct privilege escalation vector, race conditions in kernel drivers can sometimes be exploited for denial of service attacks by repeatedly triggering the crash condition during device enumeration or hotplug events. Understanding such synchronization flaws helps in hardening driver code against both accidental failures and intentional abuse scenarios that target resource management logic within the operating system core.