CVE-2026-80828: ALSA: usb-audio: Complete cleanup after system-resume errors

Published Sep 4, 2026
·
Updated

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. usbaudioresume() jumps to errout when sndusbpcmresume() or sndusbmixerresume() fails. The error path skips the out: block, which restores D0 and decrements chip->numsuspendedintf.

The card stays in SNDRVCTLPOWERD3hot, so later control access blocks in sndpowerrefandwait(). USB core logs an interface resume callback error. It does not retry that callback, so a later callback cannot complete the skipped cleanup.

usbaudiosuspend() increments numsuspendedintf 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 runtimeerror 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 errout past the D0 restore. Commit 862b2509d157c ("ALSA: usb-audio: Fix inconsistent card PM state after resume") later moved numsuspendedintf-- into the out: block. The error path now skips both operations.

No third-party code is needed to reach the error path. sndusbmixerresume() ends in sndusbmixeractivate(), which returns the result of usbsubmiturb() for devices that have a mixer status URB. Its mixer->privateresume hook can also fail through scarlett2initnotify(). sndusbpcmresume() issues a SETCUR 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 systemsuspend is nonzero. Continue to return runtime-resume errors through errout. 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 sndpowerrefandwait() 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 Software

1 affected component
Linux kernel (ALSA usb-audio)

Remediation

Recommended actions to resolve this vulnerability, in priority order.

  1. Upgrade

    Upgrade to a fixed release to a version that resolves this vulnerability.

    Patch 862b2509d157c
  2. Operational

    Reboot systems affected by the described ALSA usb-audio system-resume error, since a failed system resume can leave the card unusable until reboot and later callbacks may not recover the device.

Event History

Sep 4, 2026
CVE Published
via MITRE·03:54 PM
Data Sourced
via MITRE·03:54 PM
Description

Frequently Asked Questions

1

Which systems are exposed to the failure condition?

Linux systems using ALSA USB-audio are affected when a system resume occurs and either the PCM or mixer resume operation fails. The issue is tied to system suspend/resume handling, not the normal successful resume path.

2

How can I recognize that a device has hit this issue?

The USB audio card can remain unusable until reboot, with its control power state left at SNDRV_CTL_POWER_D3hot. Later control access can block in snd_power_ref_and_wait(), and USB core may log an interface resume callback error.

3

What can be done if the affected kernel cannot be updated immediately?

A reboot restores the card after the failure has occurred. The available data does not describe a configuration workaround that prevents the failed system-resume cleanup path.

4

Does the same cleanup behavior apply to runtime-resume failures?

No. The described cleanup is specifically for system-resume errors; applying it to runtime-resume errors would incorrectly alter the suspended-interface count, because runtime PM may retry certain errors without another suspend callback.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203