linux-kernel - Re: bisected regression in v5.11-rc1 snd-usb-audio

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 22 Jan 2021 10:03:48 +0000
From:   Jamie Heilman <jamie@...ible.transient.net>
To:     Takashi Iwai <tiwai@...e.de>
Cc:     tiwai@...e.com, linux-kernel@...r.kernel.org
Subject: Re: bisected regression in v5.11-rc1 snd-usb-audio

Takashi Iwai wrote:
> You seem hitting a firmware bug, and it doesn't look like the only
> case.  Interestingly, the backport of 5.11 USB-audio stuff on 5.3
> kernel on openSUSE Leap 15.2 caused a similar bug on Steinberg device,
> while it worked with 5.11-rc.  So I thought this specific with the
> older kernel (in USB core changes or such), but my guess seems wrong,
> and the bug looks remaining in 5.11 for some cases.
> 
> Below is the fix patch.  Please give it a try.
> 
> 
> thanks,
> 
> Takashi
> 
> -- 8< --
> From: Takashi Iwai <tiwai@...e.de>
> Subject: [PATCH] ALSA: usb-audio: workaround for iface reset issue
> 
> The recently introduced sample rate validation code seems causing a
> problem on some devices; namely, after performing this, the bus gets
> screwed and it influences even on other USB devices.
> As a quick workaround, perform it only for the necessary devices;
> currently MOTU devices are known to need the valid altset checks, so
> filter out other devices.
> 
> Fixes: 93db51d06b32 ("ALSA: usb-audio: Check valid altsetting at parsing rates for UAC2/3")
> Reported-by: Jamie Heilman <jamie@...ible.transient.net>
> BugLink: https://bugzilla.suse.com/show_bug.cgi?id=1178203
> Signed-off-by: Takashi Iwai <tiwai@...e.de>
> ---
>  sound/usb/format.c | 11 +++++++++++
>  1 file changed, 11 insertions(+)
> 
> diff --git a/sound/usb/format.c b/sound/usb/format.c
> index 9ebc5d202c87..e6ff317a6785 100644
> --- a/sound/usb/format.c
> +++ b/sound/usb/format.c
> @@ -466,6 +466,17 @@ static int validate_sample_rate_table_v2v3(struct snd_usb_audio *chip,
>  	unsigned int nr_rates;
>  	int i, err;
>  
> +	/* performing the rate verification may lead to unexpected USB bus
> +	 * behavior afterwards by some unknown reason.  Do this only for the
> +	 * known devices.
> +	 */
> +	switch (USB_ID_VENDOR(chip->usb_id)) {
> +	case 0x07fd: /* MOTU */
> +		break;
> +	default:
> +		return 0; /* don't perform the validation as default */
> +	}
> +
>  	table = kcalloc(fp->nr_rates, sizeof(*table), GFP_KERNEL);
>  	if (!table)
>  		return -ENOMEM;

Well, with this patch, while I can get it to seemingly initialize
without errors by replugging, I can't actually get it to work.  Jack
says:

Starting jack server...
JACK server starting in realtime mode with priority 10
self-connect-mode is "Don't restrict self connect requests"
Acquired audio card Audio1
creating alsa driver ... hw:CARD=hiFace2,DEV=0|-|1024|3|96000|0|0|nomon|swmeter|-|32bit
ERROR: ALSA: Cannot open PCM device alsa_pcm for playback. Falling back to capture-only mode
Released audio card Audio1
ERROR: Cannot initialize driver
ERROR: JackServer::Open failed with -1
ERROR: Failed to open server

here's what aplay does when it tries:

aplay: main:830: audio open error: Invalid argument

strace of that says:
openat(AT_FDCWD, "/dev/snd/pcmC1D0p", O_RDWR|O_NONBLOCK|O_CLOEXEC) = -1 EINVAL (Invalid argument)

I dug up a different USB sound device (bithead) and plugged it in, it
still works just fine with the same commands.

The only difference I see in the alsa-info output is that

        control.7 {
                iface CARD
                name 'Keep Interface'
                value false
                comment {
                        access 'read write'
                        type BOOLEAN
                        count 1
                }
        }

has gone missing.  I've attached it incase you can spot something I
didn't (obviously the cards are in a different order which makes
things somewhat tedious for a direct comparison).  Apart from the
device number on the usb bus, the lsusb -vvv output is the same as
it was in with 5.10.9.

-- 
Jamie Heilman                     http://audible.transient.net/~jamie/

View attachment "v5.11.0-rc4-00164-g83d09ad4b950-dirty-alsa-info.txt" of type "text/plain" (39080 bytes)