CVE-2026-80815: ALSA: scarlett2: Use a private URB for the notification endpoint
In the Linux kernel, the following vulnerability has been resolved:
ALSA: scarlett2: Use a private URB for the notification endpoint
scarlett2initnotify() used mixer->urb, which sndusbmixerstatuscreate() 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 cmddone is left zeroed because it is initialised past that check and nowhere else. scarlett2usbinit() then issues SCARLETT2USBINIT1 and waitforcompletiontimeout() would crash adding to the zeroed wait.head.
Use a separate URB in scarlett2data, as done for FCP, and initialise cmddone in scarlett2initprivate(). mixer.c was also freeing the URB in sndusbmixerfree() and resubmitting it in sndusbmixeractivate(), so scarlett2 must now do both: add scarlett2cleanupurb(), called from privatefree and privatesuspend, and a privateresume callback to re-establish the URB after resume. scarlett2initnotify() is reached from there, and the URB kill path in scarlett2notify() completes cmddone, leaving a stale count that would satisfy the next command's wait before the device ACKs. Use reinitcompletion() to clear it.
Also free the URB if the transfer buffer allocation fails, and both if usbsubmiturb() fails. Move scarlett2initnotify() up next to scarlett2cleanupurb() so scarlett2initprivate() can reference it without a forward declaration.
Affected Software
Event History
Frequently Asked Questions
Which systems are affected in practice?
Systems using the Linux kernel ALSA scarlett2 driver are affected when a supported device exposes a UAC2 status interrupt endpoint. In that configuration, the mixer-managed status URB prevents the driver from submitting its notification URB.
When does the failure occur?
The failure occurs during scarlett2 USB initialization after the driver sends SCARLETT2_USB_INIT_1 and waits for command completion. Because cmd_done remains uninitialized, wait_for_completion_timeout() can crash while operating on its zeroed wait queue head.
Does suspend and resume matter for the fix?
Yes. The driver must clean up its private notification URB during private free and suspend, then re-establish it through a private resume callback after resume. This is necessary because the mixer code separately frees and resubmits its own URB.