kernel.git/sound/usb/pcm.c, branch master

ALSA: usb-audio: Use the right limit for PCM OOB check

2026-01-21T08:22:12Z

The recent fix commit for addressing the OOB access of PCM URB data buffer caused a regression on Behringer UMC2020HD device, resulting in choppy sound. The fix used ep->max_urb_frames for the upper limit check, and this is no right value to be referred. Use the actual buffer size (ctx->buffer_size) as the upper limit instead, which also avoids the regression on the device above. Fixes: ef5749ef8b30 ("ALSA: usb-audio: Prevent excessive number of frames") Link: https://bugzilla.kernel.org/show_bug.cgi?id=220997 Link: https://patch.msgid.link/20260121082025.718748-1-tiwai@suse.de Signed-off-by: Takashi Iwai

ALSA: usb-audio: Prevent excessive number of frames

2026-01-13T14:05:45Z

In this case, the user constructed the parameters with maxpacksize 40 for rate 22050 / pps 1000, and packsize[0] 22 packsize[1] 23. The buffer size for each data URB is maxpacksize * packets, which in this example is 40 * 6 = 240; When the user performs a write operation to send audio data into the ALSA PCM playback stream, the calculated number of frames is packsize[0] * packets = 264, which exceeds the allocated URB buffer size, triggering the out-of-bounds (OOB) issue reported by syzbot [1]. Added a check for the number of single data URB frames when calculating the number of frames to prevent [1]. [1] BUG: KASAN: slab-out-of-bounds in copy_to_urb+0x261/0x460 sound/usb/pcm.c:1487 Write of size 264 at addr ffff88804337e800 by task syz.0.17/5506 Call Trace: copy_to_urb+0x261/0x460 sound/usb/pcm.c:1487 prepare_playback_urb+0x953/0x13d0 sound/usb/pcm.c:1611 prepare_outbound_urb+0x377/0xc50 sound/usb/endpoint.c:333 Reported-by: syzbot+6db0415d6d5c635f72cb@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=6db0415d6d5c635f72cb Tested-by: syzbot+6db0415d6d5c635f72cb@syzkaller.appspotmail.com Signed-off-by: Edward Adam Davis Link: https://patch.msgid.link/tencent_9AECE6CD2C7A826D902D696C289724E8120A@qq.com Signed-off-by: Takashi Iwai

ALSA: usb-audio: Use guard() for spin locks

2025-09-10T11:20:01Z

Clean up the code using guard() for spin locks. Merely code refactoring, and no behavior change. Signed-off-by: Takashi Iwai

ALSA: usb-audio: Use auto-cleanup for shutdown locks

2025-08-13T15:39:28Z

Introduce an auto-cleanup macro for the temporary shutdown locks for USB-audio, and replace the manual lock/unlock pairs with it. Namely, the former err = snd_usb_lock_shutdown(chip); if (err < 0) return err; .... snd_usb_unlock_shutdown(chip); is replaced with CLASS(snd_usb_lock, pm)(chip); if (pm.err < 0) return pm.err; .... with the automatic unlocking. Link: https://patch.msgid.link/20250811101647.8637-1-tiwai@suse.de Signed-off-by: Takashi Iwai

ALSA: usb-audio: Replace manual mutex/spinlock with guard()

2025-08-12T06:36:17Z

This is another code cleanup by replacing the manual mutex or spinlock with guard() macros. usb_audio_disconnect() is slightly refactored (split to another function) to apply guard() cleanly, but the rest are rather straightforward conversions. No functional changes but only code refactoring. Link: https://patch.msgid.link/20250811082019.31052-1-tiwai@suse.de Signed-off-by: Takashi Iwai

ALSA: usb-audio: Don't use printk_ratelimit for debug prints

2025-08-02T14:17:50Z

printk_ratelimit is deprecated, since it shares state with all other printk sites. Additionally, the suppression message is printed at warning level even though the actual messages are printed at debug and are (usually) invisible! This can result in thousands of messages like retire_capture_urb: 4992 callbacks suppressed in the console, and can inhibit debugging since it is unclear what the source of the suppressed callbacks is. Switch to dev_dbg_ratelimited which doesn't print anything unless debug is enabled. Signed-off-by: Sean Anderson Link: https://patch.msgid.link/20250801154710.739464-1-sean.anderson@linux.dev Signed-off-by: Takashi Iwai

ALSA: usb-audio: Prevent starting of audio stream if in use

2025-04-11T11:02:30Z

With USB audio offloading, an audio session is started from the ASoC platform sound card and PCM devices. Likewise, the USB SND path is still readily available for use, in case the non-offload path is desired. In order to prevent the two entities from attempting to use the USB bus, introduce a flag that determines when either paths are in use. If a PCM device is already in use, the check will return an error to userspace notifying that the stream is currently busy. This ensures that only one path is using the USB substream. Reviewed-by: Pierre-Louis Bossart Signed-off-by: Wesley Cheng Acked-by: Mark Brown Link: https://lore.kernel.org/r/20250409194804.3773260-12-quic_wcheng@quicinc.com Signed-off-by: Greg Kroah-Hartman

ALSA: usb-audio: Export USB SND APIs for modules

2025-04-11T11:02:30Z

Some vendor modules will utilize useful parsing and endpoint management APIs to start audio playback/capture. Reviewed-by: Pierre-Louis Bossart Tested-by: Puma Hsu Tested-by: Daehwan Jung Signed-off-by: Wesley Cheng Acked-by: Mark Brown Link: https://lore.kernel.org/r/20250409194804.3773260-9-quic_wcheng@quicinc.com Signed-off-by: Greg Kroah-Hartman

ALSA: usb-audio: Fix broken resume due to UAC3 power state

2023-06-16T07:28:08Z

As reported in the bugzilla below, the PM resume of a UAC3 device may fail due to the incomplete power state change, stuck at D1. The reason is that the driver expects the full D0 power state change only at hw_params, while the normal PCM resume procedure doesn't call hw_params. For fixing the bug, we add the same power state update to D0 at the prepare callback, which is certainly called by the resume procedure. Note that, with this change, the power state change in the hw_params becomes almost redundant, since snd_usb_hw_params() doesn't touch the parameters (at least it tires so). But dropping it is still a bit risky (e.g. we have the media-driver binding), so I leave the D0 power state change in snd_usb_hw_params() as is for now. Fixes: a0a4959eb4e9 ("ALSA: usb-audio: Operate UAC3 Power Domains in PCM callbacks") Cc: Link: https://bugzilla.kernel.org/show_bug.cgi?id=217539 Link: https://lore.kernel.org/r/20230612132818.29486-1-tiwai@suse.de Signed-off-by: Takashi Iwai

ALSA: usb-audio: Fix recursive locking at XRUN during syncing

2023-03-21T06:10:43Z

The recent support of low latency playback in USB-audio driver made the snd_usb_queue_pending_output_urbs() function to be called via PCM ack ops. In the new code path, the function is performed already in the PCM stream lock. The problem is that, when an XRUN is detected, the function calls snd_pcm_xrun() to notify, but snd_pcm_xrun() is supposed to be called only outside the stream lock. As a result, it leads to a deadlock of PCM stream locking. For avoiding such a recursive locking, this patch adds an additional check to the code paths in PCM core that call the ack callback; now it checks the error code from the callback, and if it's -EPIPE, the XRUN is handled in the PCM core side gracefully. Along with it, the USB-audio driver code is changed to follow that, i.e. -EPIPE is returned instead of the explicit snd_pcm_xrun() call when the function is performed already in the stream lock. Fixes: d5f871f89e21 ("ALSA: usb-audio: Improved lowlatency playback support") Reported-and-tested-by: John Keeping Link: https://lore.kernel.org/r/20230317195128.3911155-1-john@metanate.com Reviewed-by: Jaroslav Kysela Reviewed-by; Takashi Sakamoto Link: https://lore.kernel.org/r/20230320142838.494-1-tiwai@suse.de Signed-off-by: Takashi Iwai