CVE-2026-80816
NoneCVSS
—
EPSS
0.2%
Published
Sep 4, 2026
CISA due date
—
Cloudanix analysis
A bug in Linux sound handling for some USB audio gear can make the computer crash unexpectedly.
- Exploitation
- Local Privilege
- Attacker needs
- Local User
- Complexity
- Moderate
- Impact
- Denial Of Service
- Component
- OS kernel
- Class
- Race Condition
- Remediation
- Upgrade
- Effort
- Medium
- Patch risk
- Low
What it actually does
Race condition in ALSA FCP notification handling causes use of an uninitialized completion structure and incorrect URB lifetime management, leading to kernel crashes or potential memory corruption during mixer initialization and suspend/resume cycles.
Why it matters to the business
Linux systems handling USB audio devices may experience sudden kernel crashes and service interruptions, increasing operational downtime for audio workloads; low EPSS and absence from KEV indicate limited immediate external threat but still require patching within normal maintenance windows.
How an attack unfolds
A local attacker connects a USB audio device exposing a UAC2 status endpoint, triggers ALSA mixer and FCP initialization paths, then exercises suspend/resume or reinit sequences so that cmd_done remains zeroed or holds a stale count, causing wait_for_completion_timeout to crash or return early.
How to fix it
Upgrade the Linux kernel to a version containing the private URB allocation in fcp_data, cmd_done initialization in fcp_init_private, and reinit_completion usage in fcp_notify; rebuild and reboot affected systems.
How to confirm the fix worked
Inspect kernel source or running binary for separate URB in fcp_data, initialization of cmd_done before first use, and reinit_completion call; verify no mixer->urb reuse in fcp_init_notify and test suspend/resume cycles on devices with status endpoints.
Typical attack path
- Connect USB audio device with status interrupt endpoint
- Trigger snd_usb_mixer_status_create and fcp_init_notify
- Perform suspend/resume or device reinit to hit early return and stale completion
- Issue audio command that waits on zeroed or stale cmd_done
- Kernel oops or panic occurs
How to detect it
Search kernel logs and dmesg for oops/panic strings mentioning fcp_init_notify, fcp_notify, wait_for_completion_timeout, or mixer URB operations around USB audio device attach or resume events; correlate with device enumeration timestamps.
- fcp_init_notify
- fcp_notify
- cmd_done
- wait_for_completion_timeout
- fcp_reinit
- ALSA.*URB
- mixer->urb
What your security team should do
- Apply kernel updates containing the FCP private URB fix as soon as vendor packages are available
- Restrict untrusted USB audio devices via USBGuard or udev rules until patched
- Monitor kernel logs for ALSA FCP related oops after device attach or resume events
- Include this class of URB lifetime bugs in future kernel hardening reviews
The record
In the Linux kernel, the following vulnerability has been resolved: ALSA: FCP: Use a private URB for the notification endpoint fcp_init_notify() used mixer->urb, which snd_usb_mixer_status_create() allocates for the optional UAC2 status interrupt endpoint and mixer.c kills, resubmits and frees. On a device with that endpoint, fcp_init_notify()'s "already set up" early return fires on the status URB and returns success without doing anything. No FCP notification URB is submitted, and cmd_done is left zeroed because it is initialised past that early return and nowhere else. fcp_init() then issues init1_opcode and wait_for_completion_timeout() would crash adding to the zeroed wait.head. fcp_cleanup_urb() would also kill and free mixer.c's status URB. Use a separate URB in fcp_data, and initialise cmd_done in fcp_init_private() where fcp_data is allocated. fcp_init_notify() is reached again after suspend via fcp_reinit(), and the URB kill path in fcp_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.
Affected packages
| Ecosystem | Package | Introduced | Fixed |
|---|