linux-kernel - Re: [PATCH AUTOSEL 5.4 057/130] ALSA: usb-audio: Check valid altsetting at parsing rates for UAC2/3

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:   Wed, 23 Dec 2020 08:09:41 +0100
From:   Takashi Iwai <tiwai@...e.de>
To:     Sasha Levin <sashal@...nel.org>
Cc:     linux-kernel@...r.kernel.org, stable@...r.kernel.org,
        Dylan Robinson <dylan_robinson@...u.com>,
        Keith Milner <kamilner@...erlative.org>,
        alsa-devel@...a-project.org
Subject: Re: [PATCH AUTOSEL 5.4 057/130] ALSA: usb-audio: Check valid altsetting at parsing rates for UAC2/3

On Wed, 23 Dec 2020 03:17:00 +0100,
Sasha Levin wrote:
> 
> From: Takashi Iwai <tiwai@...e.de>
> 
> [ Upstream commit 93db51d06b32227319dae2ac289029ccf1b33181 ]
> 
> The current driver code assumes blindly that all found sample rates for
> the same endpoint from the UAC2 and UAC3 descriptors can be used no
> matter which altsetting, but actually this was wrong: some devices
> accept only limited sample rates in each altsetting.  For determining
> which altsetting supports which rate, we need to verify each sample rate
> and check the validity via UAC2_AS_VAL_ALT_SETTINGS.  This control
> reports back the available altsettings as a bitmap.
> 
> This patch implements the missing piece above, the verification and
> reconstructs the sample rate tables based on the result.
> 
> An open question is how to deal with the altsettings that ended up
> with no valid sample rates after verification.  At least, there is a
> device that showed this problem although the sample rates did work in
> the later usage (see bug link).  For now, we accept such an altset as
> is, assuming that it's a firmware bug.
> 
> Reported-by: Dylan Robinson <dylan_robinson@...u.com>
> Tested-by: Keith Milner <kamilner@...erlative.org>
> Tested-by: Dylan Robinson <dylan_robinson@...u.com>
> BugLink: https://bugzilla.suse.com/show_bug.cgi?id=1178203
> Link: https://lore.kernel.org/r/20201123085347.19667-4-tiwai@suse.de
> Signed-off-by: Takashi Iwai <tiwai@...e.de>
> Signed-off-by: Sasha Levin <sashal@...nel.org>

Please drop this for 5.4 or older.  At least this caused some problem
on 5.3 kernel that confused USB core by some reason while it works
fine with the recent upstream.


thanks,

Takashi