[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <Yps52Chdx5AvSgTp@sirena.org.uk>
Date: Sat, 4 Jun 2022 11:54:16 +0100
From: Mark Brown <broonie@...nel.org>
To: Pavel Machek <pavel@....cz>
Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
theflamefire89@...il.com, linux-kernel@...r.kernel.org,
stable@...r.kernel.org
Subject: Re: [PATCH 4.9 34/48] ASoC: ops: Reject out of bounds values in
snd_soc_put_volsw_sx()
On Fri, Jun 03, 2022 at 12:28:09PM +0200, Mark Brown wrote:
> On Fri, Jun 03, 2022 at 12:06:13PM +0200, Pavel Machek wrote:
>
> > We are getting reports that this commit breaks audio on some
> > phones... and indeed it looks like "+ min" is missing in first condition:
>
> > https://github.com/baunilla/android_kernel_xiaomi_rosy/commit/969b9d366c1e9564e173aea325ec544dcd7804ff
>
> > val = ucontrol->value.integer.value[0];
> > - if (mc->platform_max && val > mc->platform_max)
> > + if (mc->platform_max && ((int)val + min) > mc->platform_max)
> >  return -EINVAL;
>
> > What needs to be done to get this fixed?
>
> The downstream kernel platform_max configuration should really be
> using the user visible value, not a direct register value. Note
> that some of the Qualcomm vendor trees have modifictions to the
> semantics of some of the controls which cause issues, and partly
> due to this confusion there should be some fixes for their
> upstream drivers coming soon.
Actually potentially we want to revert the handling of
platform_max only. Do we know where these systems are getting
their platform_max values from (a machine driver or sometehing
else?)? Sadly these controls were not even self consistent so
it's not clear which behaviour to fix, though fortunately it's
all in the areas where the userspaces were out of spec trying to
use the behaviour.
Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)
Powered by blists - more mailing lists