kernel/linux.git/sound/usb/clock.c, branch v6.18.21

ALSA: usb-audio: Fix out of bounds reads when finding clock sources

2024-11-25T14:48:22+00:00

The current USB-audio driver code doesn't check bLength of each descriptor at traversing for clock descriptors. That is, when a device provides a bogus descriptor with a shorter bLength, the driver might hit out-of-bounds reads. For addressing it, this patch adds sanity checks to the validator functions for the clock descriptor traversal. When the descriptor length is shorter than expected, it's skipped in the loop. For the clock source and clock multiplier descriptors, we can just check bLength against the sizeof() of each descriptor type. OTOH, the clock selector descriptor of UAC2 and UAC3 has an array of bNrInPins elements and two more fields at its tail, hence those have to be checked in addition to the sizeof() check. Reported-by: Benoît Sevens Cc: Link: https://lore.kernel.org/20241121140613.3651-1-bsevens@google.com Link: https://patch.msgid.link/20241125144629.20757-1-tiwai@suse.de Signed-off-by: Takashi Iwai

ALSA: usb-audio: Support multiple control interfaces

2024-08-12T14:17:46+00:00

Registering Numark Party Mix II fails with error 'bogus bTerminalLink 1'. The problem stems from the driver not being able to find input/output terminals required to configure audio streaming. The information about those terminals is stored in AudioControl Interface. Numark device contains 2 AudioControl Interfaces and the driver checks only one of them. According to the USB standard, a device can have multiple audio functions, each represented by Audio Interface Collection. Every audio function is considered to be closed box and will contain unique AudioControl Interface and zero or more AudioStreaming and MIDIStreaming Interfaces. The Numark device adheres to the standard and defines two audio functions: - MIDIStreaming function - AudioStreaming function It starts with MIDI function, followed by the audio function. The driver saves the first AudioControl Interface in `snd_usb_audio` structure associated with the entire device. It then attempts to use this interface to query for terminals and clocks. However, this fails because the correct information is stored in the second AudioControl Interface, defined in the second Audio Interface Collection. This patch introduces a structure holding association between each MIDI/Audio Interface and its corresponding AudioControl Interface, instead of relying on AudioControl Interface defined for the entire device. This structure is populated during usb probing phase and leveraged later when querying for terminals and when sending USB requests. Alternative solutions considered include: - defining a quirk for Numark where the order of interface is manually changed, or terminals are hardcoded in the driver. This solution would have fixed only this model, though it seems that device is USB compliant, and it also seems that other devices from this company may be affected. What's more, it looks like products from other manufacturers have similar problems, i.e. Rane One DJ console - keeping a list of all AudioControl Interfaces and querying all of them to find required information. That would have solved my problem and have low probability of breaking other devices, as we would always start with the same logic of querying first AudioControl Interface. This solution would not have followed the standard though. This patch preserves the `snd_usb_audio.ctrl_intf` variable, which holds the first AudioControl Interface, and uses it as a fallback when some interfaces are not parsed correctly and lack an associated AudioControl Interface, i.e., when configured via quirks. Link: https://bugzilla.kernel.org/show_bug.cgi?id=217865 Signed-off-by: Karol Kosik Link: https://patch.msgid.link/AS8P190MB1285893F4735C8B32AD3886BEC852@AS8P190MB1285.EURP190.PROD.OUTLOOK.COM Signed-off-by: Takashi Iwai

ALSA: usb-audio: Ignore clock selector errors for single connection

2024-02-01T14:29:40+00:00

For devices with multiple clock sources connected to a selector, we need to check what a clock selector control request has returned. This is needed to ensure that a requested clock source is indeed selected and for autoclock feature to work. For devices with single clock source connected, if we get an error there is nothing else we can do about it. We can't skip clock selector setup as it is required by some devices. So lets just ignore error in this case. This should fix various buggy Mackie devices: [ 649.109785] usb 1-1.3: parse_audio_format_rates_v2v3(): unable to find clock source (clock -32) [ 649.111946] usb 1-1.3: parse_audio_format_rates_v2v3(): unable to find clock source (clock -32) [ 649.113822] usb 1-1.3: parse_audio_format_rates_v2v3(): unable to find clock source (clock -32) There is also interesting info from the Windows documentation [1] (this is probably why manufacturers dont't even test this feature): "The USB Audio 2.0 driver doesn't support clock selection. The driver uses the Clock Source Entity, which is selected by default and never issues a Clock Selector Control SET CUR request." Link: https://learn.microsoft.com/en-us/windows-hardware/drivers/audio/usb-2-0-audio-drivers [1] Link: https://bugzilla.kernel.org/show_bug.cgi?id=217314 Link: https://bugzilla.kernel.org/show_bug.cgi?id=218175 Link: https://bugzilla.kernel.org/show_bug.cgi?id=218342 Signed-off-by: Alexander Tsoy Link: https://lore.kernel.org/r/20240201115308.17838-1-alexander@tsoy.me Signed-off-by: Takashi Iwai

Revert "ALSA: usb-audio: Skip setting clock selector for single connections"

2024-01-29T08:07:57+00:00

This reverts commit 67794f882adca00d043899ac248bc002751da9f6. We need to explicitly set up the clock selector to workaround a problem with the Behringer mixers. This was originally done in d2e8f641257d ("ALSA: usb-audio: Explicitly set up the clock selector") The problem with MOTU M Series mentioned in commit message was fixed in a different way by checking control capabilities of clock selectors. Signed-off-by: Alexander Tsoy Link: https://lore.kernel.org/r/20240128132338.819273-1-alexander@tsoy.me Signed-off-by: Takashi Iwai

ALSA: usb-audio: Support read-only clock selector control

2024-01-26T15:07:32+00:00

Clock selector control might be read-only. Add corresponding checks to prevent sending control requests that would fail. Signed-off-by: Alexander Tsoy Link: https://lore.kernel.org/r/20240125205457.28258-1-alexander@tsoy.me Signed-off-by: Takashi Iwai

ALSA: usb-audio: Skip setting clock selector for single connections

2024-01-23T14:10:25+00:00

Since commit 086b957cc17f5 ("ALSA: usb-audio: Skip the clock selector inquiry for single connections") we are already skipping clock selector inquiry if only one clock source is connected, but we are still sending a set request. Lets skip that too. This should fix errors when setting a sample rate on devices that don't have any controls present within the clock selector. An example of such device is the new revision of MOTU M Series (07fd:000b): AudioControl Interface Descriptor: bLength 8 bDescriptorType 36 bDescriptorSubtype 11 (CLOCK_SELECTOR) bClockID 1 bNrInPins 1 baCSourceID(0) 2 bmControls 0x00 iClockSelector 0 Perhaps we also should check if clock selectors are readable and writeable like we already do for clock sources, but this is out of scope of this patch. Link: https://bugzilla.kernel.org/show_bug.cgi?id=217601 Signed-off-by: Alexander Tsoy Link: https://lore.kernel.org/r/20240123134635.54026-1-alexander@tsoy.me Signed-off-by: Takashi Iwai

ALSA: usb-audio: Optimize TEAC clock quirk

2022-05-31T13:09:05+00:00

Maris found out that the quirk for TEAC devices to work around the clock setup is needed to apply only when the base clock is changed, e.g. from 48000-based clocks (48000, 96000, 192000, 384000) to 44100-based clocks (44100, 88200, 176400, 352800), or vice versa, while switching to another clock with the same base clock doesn't need the (forcible) interface setup. This patch implements the optimization for the TEAC clock quirk to avoid the unnecessary interface re-setup. Fixes: 5ce0b06ae5e6 ("ALSA: usb-audio: Workaround for clock setup on TEAC devices") Reported-by: Maris Abele Cc: Link: https://lore.kernel.org/r/20220531130749.30357-1-tiwai@suse.de Signed-off-by: Takashi Iwai

ALSA: usb-audio: Workaround for clock setup on TEAC devices

2022-05-21T06:49:44+00:00

Maris reported that TEAC UD-501 (0644:8043) doesn't work with the typical "clock source 41 is not valid, cannot use" errors on the recent kernels. The currently known workaround so far is to restore (partially) what we've done unconditionally at the clock setup; namely, re-setup the USB interface immediately after the clock is changed. This patch re-introduces the behavior conditionally for TEAC devices. Further notes: - The USB interface shall be set later in snd_usb_endpoint_configure(), but this seems to be too late. - Even calling usb_set_interface() right after sne_usb_init_sample_rate() doesn't help; so this must be related with the clock validation, too. - The device may still spew the "clock source 41 is not valid" error at the first clock setup. This seems happening at the very first try of clock setup, but it disappears at later attempts. The error is likely harmless because the driver retries the clock setup (such an error is more or less expected on some devices). Fixes: bf6313a0ff76 ("ALSA: usb-audio: Refactor endpoint management") Reported-and-tested-by: Maris Abele Cc: Link: https://lore.kernel.org/r/20220521064627.29292-1-tiwai@suse.de Signed-off-by: Takashi Iwai

ALSA: usb-audio: fix null pointer dereference on pointer cs_desc

2021-10-26T06:05:23+00:00

The pointer cs_desc return from snd_usb_find_clock_source could be null, so there is a potential null pointer dereference issue. Fix this by adding a null check before dereference. Signed-off-by: Chengfeng Ye Link: https://lore.kernel.org/r/20211024111736.11342-1-cyeaa@connect.ust.hk Signed-off-by: Takashi Iwai

ALSA: usb-audio: fix comment reference in __uac_clock_find_source

2021-09-28T08:17:08+00:00

snd_usb_find_clock_source and snd_usb_find_clock_selector are helper macros that look at an entity id and validate that this entity id is in fact a clock source or a clock selector. The present comments inside __uac_clock_find_source give the reader the impression we're looking for an entity id. We're looking for an entity id indeed, the clock source, but since __uac_clock_find_source is recursive, we're also looking *at* the entity ids, in the search for the one clock source. Fix the comment so we don't give readers a wrong idea. Signed-off-by: Geraldo Nascimento Link: https://lore.kernel.org/r/YU6Kj05oOqRmhJDf@geday Signed-off-by: Takashi Iwai