CVE-2026-80816: ALSA: FCP: Use a private URB for the notification endpoint
In the Linux kernel, the following vulnerability has been resolved:
ALSA: FCP: Use a private URB for the notification endpoint
fcpinitnotify() used mixer->urb, which sndusbmixerstatuscreate() allocates for the optional UAC2 status interrupt endpoint and mixer.c kills, resubmits and frees. On a device with that endpoint, fcpinitnotify()'s "already set up" early return fires on the status URB and returns success without doing anything. No FCP notification URB is submitted, and cmddone is left zeroed because it is initialised past that early return and nowhere else. fcpinit() then issues init1opcode and waitforcompletiontimeout() would crash adding to the zeroed wait.head. fcpcleanupurb() would also kill and free mixer.c's status URB.
Use a separate URB in fcpdata, and initialise cmddone in fcpinitprivate() where fcpdata is allocated. fcpinitnotify() is reached again after suspend via fcpreinit(), and the URB kill path in fcpnotify() completes cmddone, leaving a stale count that would satisfy the next command's wait before the device ACKs. Use reinitcompletion() to clear it.
Event History
Frequently Asked Questions
Which systems are affected by this issue?
The affected path is reached on Linux systems using the ALSA FCP driver with a device that has the optional UAC2 status interrupt endpoint. In that configuration, the FCP notification setup can mistakenly reuse the mixer status URB.
What can happen when the vulnerable path is triggered?
During FCP initialization, the completion object can remain uninitialized, and waiting for the initialization command can crash. The cleanup path can also kill and free the mixer component's status URB.
Does suspend and resume affect the behavior?
Yes. The notification setup is reached again after suspend through FCP reinitialization; a stale completion count can cause a later command wait to succeed before the device acknowledges the command.