linux-kernel - Re: [alsa-devel] [PATCH] ASoC: nau8824: use 64-bit arithmetic instead of 32-bit

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] [day] [month] [year] [list]

Date:   Thu, 5 Jul 2018 19:09:05 -0700
From:   Trent Piepho <xyzzy@...akeasy.org>
To:     "Gustavo A. R. Silva" <gustavo@...eddedor.com>
Cc:     Liam Girdwood <lgirdwood@...il.com>,
        Mark Brown <broonie@...nel.org>,
        Jaroslav Kysela <perex@...ex.cz>,
        Takashi Iwai <tiwai@...e.com>, alsa-devel@...a-project.org,
        linux-kernel@...r.kernel.org
Subject: Re: [alsa-devel] [PATCH] ASoC: nau8824: use 64-bit arithmetic instead
 of 32-bit

On Thu, Jul 5, 2018 at 6:06 AM, Gustavo A. R. Silva
<gustavo@...eddedor.com> wrote:
> Add suffix ULL to constant 256 in order to give the compiler complete
> information about the proper arithmetic to use.
>
> Notice that such constant is used in a context that expects an
> expression of type u64 (64 bits, unsigned) and the following
> expression is currently being evaluated using 32-bit arithmetic:
>
> 256 * fs * 2 * mclk_src_scaling[i].param
>
> Addresses-Coverity-ID: 1432039 ("Unintentional integer overflow")
> Signed-off-by: Gustavo A. R. Silva <gustavo@...eddedor.com>
> ---
>  sound/soc/codecs/nau8824.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/sound/soc/codecs/nau8824.c b/sound/soc/codecs/nau8824.c
> index 6bd1445..468d514 100644
> --- a/sound/soc/codecs/nau8824.c
> +++ b/sound/soc/codecs/nau8824.c
> @@ -1274,7 +1274,7 @@ static int nau8824_calc_fll_param(unsigned int fll_in,
>         fvco_max = 0;
>         fvco_sel = ARRAY_SIZE(mclk_src_scaling);
>         for (i = 0; i < ARRAY_SIZE(mclk_src_scaling); i++) {
> -               fvco = 256 * fs * 2 * mclk_src_scaling[i].param;
> +               fvco = 256ULL * fs * 2 * mclk_src_scaling[i].param;

This would be better written as fvco = (256 * 2 *
mclk_src_scaling[i].param) * (u64)fs;

There no reason the entire expression must use 64 bit multiplies,
since the left side
above is know to fit in 32-bits.

The code could be more efficient if mclk_src_scaling had been sorted
by scaling ratio
instead of register value.  In fact, most of the math in this loop
could be precomputed by the
compiler if one instead though of min and max fs range for a given scaler.