linux-kernel - Re: kernel 5.4.11: problems with usb sound cards

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 for Android: free password hash cracker in your pocket

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

Message-ID: <20200203084236.GS10381@localhost>
Date:   Mon, 3 Feb 2020 09:42:36 +0100
From:   Johan Hovold <johan@...nel.org>
To:     edes <edes@....net>
Cc:     linux-usb@...r.kernel.org, linux-kernel@...r.kernel.org,
        Johan Hovold <johan@...nel.org>, Takashi Iwai <tiwai@...e.de>
Subject: Re: kernel 5.4.11: problems with usb sound cards

On Sun, Feb 02, 2020 at 08:28:16PM -0300, edes wrote:
> 
> el 2020-02-02 a las 14:41 Johan Hovold escribió:
> 
> > I realised I forgot the test to match on the device descriptor when
> > applying the blacklist. It doesn't matter currently since I only enable
> > the quirk for your device, but if you haven't tested the patch already,
> > would you mind testing the below patch instead?
> 
> Hi, Johan, thank you for looking into this. I tested your patch, and it
> works! (5.4.11 and 5.5.0).
> 
> I haven't performed extensive tests, but the card is again recognized as
> both playback and capture device. Thank you!

Perfect, thanks for testing.

Do you have a full name I can use to give you credit in the commit
message for reporting and testing?

> Is this and acceptable solution and will this patch be integrated into the
> kernel?

Yes, I think so. We've already had one related report so far, and the
blacklist mechanism should be generic enough to handle any further
devices like this.

Either way, we'll have this fixed in stable in one way or another in a
couple of weeks.

> OTOH, you said:
> 
> > Ok, so the device has a broken altsetting 3 for interface 1, where
> > endpoint 0x85 is declared as an isochronous endpoint, despite being used
> > by interface 2 as an audio endpoint:
> [...]
> > Note that the broken altsetting probably should be using endpoint 0x81
> > just like the other altsettings for that interface, 
> 
> I can't say I understand exactly what you're saying, but do you think it
> could be worth contacting the company and see if they are willing to fix
> this with a new firmware?

Yes, I guess that wouldn't hurt.

The device used to work mostly by chance as two interfaces aren't
allowed to claim the same endpoint. Fortunately, this would only ever be
an issue in one particular configuration of the device (when altsetting
3 of interface 1 was selected) and that may be one that was never used
on Linux.

Takashi may know more about how/if that third altsetting could ever end
up being set.

Johan