CVE-2026-90031: usb-storage: ene_ub6250: fix race between scan work and probe
In the Linux kernel, the following vulnerability has been resolved:
usb-storage: eneub6250: fix race between scan work and probe
eneub6250probe() calls usbstorprobe2(), which starts the usb-storage infrastructure and schedules the delayed scan work. The driver then calls enegetcardtype(), which sends an ENE command through enesendscsicmd() and the usb-storage bulk transfer helpers.
Both the delayed scan work, through usbstorBulkmaxlun(), and enegetcardtype() use us->currenturb. The scan work serializes this access with us->devmutex, but the ENE card-type probe does not. If the scan work runs while enegetcardtype() is still using us->currenturb, usbsubmiturb() warns that the URB is already active.
Serialize enegetcardtype() with us->devmutex, matching the locking used by the scan path.
Affected Software
Event History
Frequently Asked Questions
Which systems are exposed to this race?
Systems using the Linux kernel's ene_ub6250 USB-storage driver can encounter the issue during device probing, when delayed scan work overlaps with the driver's card-type detection.
How can an administrator tell whether the race has occurred?
The described symptom is a usb_submit_urb() warning indicating that the URB is already active.
What condition triggers the problem?
The delayed scan work must run while ene_get_card_type() is using us->current_urb. The two paths previously accessed that URB without matching serialization.