linux-kernel - Re: [PATCH AUTOSEL 5.10 30/62] ASoC: rt5645: add error checking to rt5645

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]

Message-ID: <YK1w+H70aqLGDaDl@sirena.org.uk>
Date:   Tue, 25 May 2021 22:49:44 +0100
From:   Mark Brown <broonie@...nel.org>
To:     Sasha Levin <sashal@...nel.org>
Cc:     linux-kernel@...r.kernel.org, stable@...r.kernel.org,
        Phillip Potter <phil@...lpotter.co.uk>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        alsa-devel@...a-project.org
Subject: Re: [PATCH AUTOSEL 5.10 30/62] ASoC: rt5645: add error checking to
 rt5645_probe function

On Mon, May 24, 2021 at 10:47:11AM -0400, Sasha Levin wrote:
> From: Phillip Potter <phil@...lpotter.co.uk>
> 
> [ Upstream commit 5e70b8e22b64eed13d5bbebcb5911dae65bf8c6b ]
> 
> Check for return value from various snd_soc_dapm_* calls, as many of
> them can return errors and this should be handled. Also, reintroduce
> the allocation failure check for rt5645->eq_param as well. Make all

Now I've looked at the patch I don't think it's appropriate for
stable, it's essentially equivalent to a patch that adds -Werror
- the changes in it are upgrading things from error messages that
would be generated by what are essentially static checks (even
though we do do them at runtime they're on hard coded strings) to
probe failures which would be a regression.  Unfortunately people
do ignore warnings like that in shipping stuff so it's possible
it's happening, we could do an audit to see if it is but it seems
like more effort than it's worth.

The only case I can think where it might help is if we're
managing to OOM during probe() but that feels very unlikely to
happen, and improved handling unlikely to make substantial
difference compared to the risk that the routing warnings are
triggering but being ignored so someone's sound stops working due
to a stable update.  Otherwise it won't do much so why risk it?

Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)