CVE-2026-80815

ALSA: scarlett2: Use a private URB for the notification endpoint

N/A
Published: September 4, 2026 at 03:13 PM UTC
Updated: October 19, 2026 at 09:17 AM UTC
1 product affected across 1 vendorLinux Kernel

Using Linux by Linux?

Get instant alerts when new vulnerabilities affect Linux - before attackers find them.

Real-time alertsTrack your software stackFree plan available
Severity
N/A
Exploit prediction
EPSS 0.2%

Description

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.

Affected

Our own answer: ranges merged, affected separated from platform-only, with confidence and review flags.

1b65088958cadab04d5d34a8615e2466b1b48ecb6.10
Vendor states this is fixed in 013448eb7b0d0b91d6168685dab10e9b41baa825 (fixed)
Vendor states this is fixed in 04df0232a6976845cd9c9e83b6c26215759be667 (fixed)
Vendor states this is fixed in 4305e4b52acc0ca67dcfdf8f73dd943dab508ae8 (fixed)
Vendor states this is fixed in cd17d6ff7b7d2b1dd9bcc80ae7b4a83773f918c6 (fixed)
Vendor states this is fixed in ecd2f83a4ddc078901e7104144cb6c5e5db3b7cf (fixed)
Vendor states this is fixed in 6.10 (unaffected)
Vendor states this is fixed in 6.12.106 (unaffected)
Vendor states this is fixed in 6.18.47 (unaffected)
Vendor states this is fixed in 7.1.11 (unaffected)
Vendor states this is fixed in 7.2.1 (unaffected)
Vendor states this is fixed in 7.3 (unaffected)
Vendor states this is fixed in 7.3-rc1 (unaffected)

Remediation

No guide yet

No remediation guidance has been written for this CVE yet, and no fixed version or vendor advisory is recorded against it.

Quick Info

StatusRECEIVED

Get alerted

Stop reading CVE feeds looking for your own stack

Track the products you run and VulnTracker tells you when a new CVE affects them — with what is known about fixing it, and nothing about the rest.

Free plan, no card