CVE-2026-80815 in Linux
Summary
by MITRE • 09/04/2026
In the Linux kernel, the following vulnerability has been resolved:
ALSA: scarlett2: Use a private URB for the notification endpoint
scarlett2_init_notify() used mixer->urb, which snd_usb_mixer_status_create() allocates for the UAC2 status interrupt endpoint and mixer.c manages. On a device with that endpoint, the "already in use" check fires on the status URB and returns 0 for success without doing anything. No notification URB is submitted, and cmd_done is left zeroed because it is initialised past that check and nowhere else. scarlett2_usb_init() then issues SCARLETT2_USB_INIT_1 and wait_for_completion_timeout() would crash adding to the zeroed wait.head.
Use a separate URB in scarlett2_data, as done for FCP, and initialise cmd_done in scarlett2_init_private(). mixer.c was also freeing the URB in snd_usb_mixer_free() and resubmitting it in snd_usb_mixer_activate(), so scarlett2 must now do both: add scarlett2_cleanup_urb(), called from private_free and private_suspend, and a private_resume callback to re-establish the URB after resume. scarlett2_init_notify() is reached from there, and the URB kill path in scarlett2_notify() completes cmd_done, leaving a stale count that would satisfy the next command's wait before the device ACKs. Use reinit_completion() to clear it.
Also free the URB if the transfer buffer allocation fails, and both if usb_submit_urb() fails. Move scarlett2_init_notify() up next to scarlett2_cleanup_urb() so scarlett2_init_private() can reference it without a forward declaration.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/04/2026
The vulnerability in the Linux kernel's ALSA Scarlett 2 driver stems from an improper sharing of USB Request Block resources between distinct functional endpoints, leading to state corruption and potential system instability. The core technical flaw lies in scarlett2_init_notify() attempting to reuse a URB allocated by snd_usb_mixer_status_create for the Universal Audio Class version 2 status interrupt endpoint. This shared resource is managed centrally by mixer.c, which performs an already-in-use check that incorrectly returns success without initializing the notification-specific components when the device possesses such an endpoint. Consequently, no dedicated notification URB is submitted to handle asynchronous events from the hardware.
This oversight results in critical state corruption because the cmd_done completion variable remains zeroed, as its initialization occurs after the flawed early return path and is never executed under these conditions. When scarlett2_usb_init subsequently issues a SCARLETT2_USB_INIT_1 command, it relies on wait_for_completion_timeout to synchronize with hardware responses. Because the underlying URB was not properly established for notifications, this synchronization mechanism interacts incorrectly with memory structures, specifically crashing by adding to a zeroed wait.head. This represents a severe reliability issue that can lead to kernel panics or undefined behavior during device initialization sequences involving specific Scarlett 2 audio interfaces.
The operational impact extends beyond initial boot-time crashes into runtime stability and power management scenarios. The original implementation failed to properly manage the lifecycle of USB resources, leaving stale completion counts that could satisfy subsequent command waits before actual hardware acknowledgment occurred. This race condition allows for potential logic errors where software proceeds assuming successful communication when none has taken place. Furthermore, improper handling during suspend and resume cycles meant that URBs were not correctly re-established after system wake events, leading to broken connectivity or further state inconsistencies upon device resumption from low-power states.
To resolve these issues, the fix involves decoupling the notification endpoint's resources from the general mixer status infrastructure by allocating a private URB within scarlett2_data, mirroring patterns used in other drivers like FCP. This architectural change ensures that each functional component manages its own USB transfer blocks independently. The solution also introduces explicit lifecycle management functions including scarlett2_cleanup_urb for proper resource deallocation during driver unbinding and suspend operations, alongside a private_resume callback to re-initialize the URB after system wake events. Additionally, reinit_completion is employed to clear stale completion states before new commands are issued, preventing race conditions where old completions might erroneously trigger subsequent waits.
Mitigation strategies for this vulnerability involve applying kernel patches that enforce strict separation of USB resource management per endpoint function. System administrators should ensure their kernels include updates addressing scarlett2 URB handling and proper initialization sequences for notification endpoints. From a development perspective, adhering to industry standards such as CWE-362 regarding concurrent execution issues is essential when managing shared hardware resources in kernel space. The fix aligns with ATT&CK technique T1059 related to command scripting by ensuring that internal driver logic does not execute based on false assumptions of successful hardware interaction due to uninitialized states or race conditions. Proper error handling for buffer allocation failures and usb_submit_urb errors must also be maintained to prevent resource leaks and ensure robust operation under all device configurations.