Back to CVE records
Not yet scoredPublished Sep 4, 2026

CVE-2026-80815ALSA: scarlett2: Use a private URB for the notification endpoint

Updated under an hour ago ()

Does this affect you?

It affects Linux. Add what you run to find out whether that includes you.

No exploitation reported and no EPSS estimate yet.

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.

CVSS
Not yet scored
Weakness (CWE)
Not given
Known exploited
Not in CISA's KEV catalog
EPSS (exploitation in the next 30 days)
Not loaded for this CVE
Assigned by
Linux
NVD analysis
Received
Record last updated
Sep 4, 2026
First seen by InfoSec Signals
Oct 9, 2026

Affected products

Affected products
Linux Linux
linux:linux (from the name)
from 1b65088958cadab04d5d34a8615e2466b1b48ecb before 013448eb7b0d0b91d6168685dab10e9b41baa825; from 1b65088958cadab04d5d34a8615e2466b1b48ecb before 4305e4b52acc0ca67dcfdf8f73dd943dab508ae8; from 1b65088958cadab04d5d34a8615e2466b1b48ecb before 04df0232a6976845cd9c9e83b6c26215759be667; from 1b65088958cadab04d5d34a8615e2466b1b48ecb before ecd2f83a4ddc078901e7104144cb6c5e5db3b7cf; from 1b65088958cadab04d5d34a8615e2466b1b48ecb before cd17d6ff7b7d2b1dd9bcc80ae7b4a83773f918c6
CNA record

References

The CVE record is authoritative. Products marked “from the name” were identified from the CNA's free-text names, not a CPE, and are matched less certainly. This product uses the NVD API but is not endorsed or certified by the NVD.

Your cookie choices
We use essential cookies to run this site, and, only with your consent, an advertising cookie from Google to measure whether our ads lead to sign-ups and subscriptions. See our for details.