Cloudanix VulnDB

CVE-2026-80828

None

CVSS

—

EPSS

0.2%

Published

Sep 4, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A bug in Linux audio handling can leave USB sound devices unusable after waking from sleep, requiring a full restart to recover.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
Moderate
Impact
Denial Of Service
Component
OS kernel
Class
Other
Remediation
Patch
Effort
Medium
Patch risk
Low

What it actually does

A system-resume error path in usb_audio_resume() skips both the D0 power-state restore and the num_suspended_intf decrement, leaving the ALSA card permanently in SNDRV_CTL_POWER_D3hot so that subsequent control operations block indefinitely in snd_power_ref_and_wait().

Why it matters to the business

Audio devices on affected Linux systems can become permanently unusable after any resume failure, forcing unplanned reboots and interrupting audio-dependent workflows until the system is restarted.

How an attack unfolds

An attacker or automated process triggers a transient USB resume failure (for example by stalling a SET_CUR request or returning -EIO from a mixer URB). The kernel error path leaves the interface count and power state inconsistent; subsequent control access hangs and the device remains unusable until reboot. No additional code execution or third-party drivers are required.

How to fix it

Apply the upstream fix that routes component-resume errors through the out: label when system_suspend is nonzero, ensuring both D0 restore and num_suspended_intf decrement always occur on system resume. Rebuild and deploy the patched kernel; runtime-resume error paths remain unchanged.

How to confirm the fix worked

After patching, reproduce a component resume failure during system suspend/resume and confirm that control interfaces remain responsive and that a subsequent suspend/resume cycle succeeds. Monitor dmesg for "interface resume error" messages that no longer strand the device.

Typical attack path

  1. Cause or observe a USB audio resume failure during system wake
  2. snd_usb_pcm_resume() or snd_usb_mixer_resume() returns an error
  3. usb_audio_resume() jumps to err_out, skipping the out: block
  4. num_suspended_intf is not decremented and the card stays in D3hot
  5. Any later snd_ctl or mixer access blocks in snd_power_ref_and_wait()
  6. Device remains unusable until full reboot

How to detect it

Search kernel logs for "usb_audio_resume" combined with later "snd_power_ref_and_wait" stalls or "interface resume callback error" entries; correlate with audio device unavailability that persists across multiple resume attempts without a reboot.

What your security team should do

  • Prioritize patching audio-enabled kernels within the normal update cycle given low EPSS and no KEV listing
  • Add kernel version checks to vulnerability scanners for the fixed commit range
  • Include USB audio resume failure logs in post-resume health checks

The record

In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: Complete cleanup after system-resume errors A failed system resume can leave the card unusable until reboot. usb_audio_resume() jumps to err_out when snd_usb_pcm_resume() or snd_usb_mixer_resume() fails. The error path skips the out: block, which restores D0 and decrements chip->num_suspended_intf. The card stays in SNDRV_CTL_POWER_D3hot, so later control access blocks in snd_power_ref_and_wait(). USB core logs an interface resume callback error. It does not retry that callback, so a later callback cannot complete the skipped cleanup. usb_audio_suspend() increments num_suspended_intf before returning success. A system-resume callback must consume the system-suspend count even if a component resume fails. Otherwise, the stranded count skews later suspend and resume cycles. Do not apply this cleanup to runtime-resume errors. Runtime PM can retry -EAGAIN or -EBUSY without another suspend callback. The count must continue to describe that suspended interface. Other runtime-resume errors latch runtime_error in the PM core and do not cause an immediate callback retry. Both parts of the system-resume error path are longstanding. Commit 88a8516a2128a ("ALSA: usbaudio: implement USB autosuspend") introduced err_out past the D0 restore. Commit 862b2509d157c ("ALSA: usb-audio: Fix inconsistent card PM state after resume") later moved num_suspended_intf-- into the out: block. The error path now skips both operations. No third-party code is needed to reach the error path. snd_usb_mixer_resume() ends in snd_usb_mixer_activate(), which returns the result of usb_submit_urb() for devices that have a mixer status URB. Its mixer->private_resume hook can also fail through scarlett2_init_notify(). snd_usb_pcm_resume() issues a SET_CUR request to a UAC3 power domain. It can return -EPIPE or -EIO when the device stalls the request. Route a component error through out: only when system_suspend is nonzero. Continue to return runtime-resume errors through err_out. Later component resume stages remain skipped. The original error still reaches USB core. A later transfer can fail if the device did not recover. I reproduced the system-resume failure on an Audient iD14 MkI with an out-of-tree diagnostic mixer resume hook. An injected -EIO on the unpatched core left control readers in uninterruptible sleep in snd_power_ref_and_wait() until a reboot. With this patch, the same failure restored control access. A second system suspend and resume also succeeded after I disabled fault injection.

Affected packages

Ecosystem Package Introduced Fixed