linux-kernel - RE: [PATCH] drivers:iio:dac make expression evaluation 64-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]

Message-ID: <PH0PR03MB67867EF2E5CE7CAA69F04B71994B9@PH0PR03MB6786.namprd03.prod.outlook.com>
Date:   Wed, 5 Jan 2022 15:36:08 +0000
From:   "Sa, Nuno" <Nuno.Sa@...log.com>
To:     Dan Carpenter <dan.carpenter@...cle.com>,
        Muhammad Usama Anjum <usama.anjum@...labora.com>
CC:     Lars-Peter Clausen <lars@...afoo.de>,
        "Hennerich, Michael" <Michael.Hennerich@...log.com>,
        Jonathan Cameron <jic23@...nel.org>,
        "Chindris, Mihail" <Mihail.Chindris@...log.com>,
        "open list:IIO SUBSYSTEM AND DRIVERS" <linux-iio@...r.kernel.org>,
        open list <linux-kernel@...r.kernel.org>,
        "kernel@...labora.com" <kernel@...labora.com>,
        "kernel-janitors@...r.kernel.org" <kernel-janitors@...r.kernel.org>
Subject: RE: [PATCH] drivers:iio:dac make expression evaluation 64-bit

> From: Dan Carpenter <dan.carpenter@...cle.com>
> Sent: Wednesday, January 5, 2022 2:39 PM
> To: Muhammad Usama Anjum <usama.anjum@...labora.com>
> Cc: Lars-Peter Clausen <lars@...afoo.de>; Hennerich, Michael
> <Michael.Hennerich@...log.com>; Jonathan Cameron
> <jic23@...nel.org>; Chindris, Mihail <Mihail.Chindris@...log.com>;
> open list:IIO SUBSYSTEM AND DRIVERS <linux-iio@...r.kernel.org>;
> open list <linux-kernel@...r.kernel.org>; kernel@...labora.com;
> kernel-janitors@...r.kernel.org
> Subject: Re: [PATCH] drivers:iio:dac make expression evaluation 64-bit
> 
> [External]
> 
> On Wed, Dec 22, 2021 at 12:20:32AM +0500, Muhammad Usama Anjum
> wrote:
> > Two 32-bit values are being evaluated using 32-bit arithmetic and
> then
> > passed to s64 type. It is wrong. Expression should be evaluated using
> > 64-bit arithmetic and then passed.
> >
> > Fixes: 8f2b54824b ("drivers:iio:dac: Add AD3552R driver support")
> > Signed-off-by: Muhammad Usama Anjum
> <usama.anjum@...labora.com>
> > ---
> >  drivers/iio/dac/ad3552r.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/iio/dac/ad3552r.c b/drivers/iio/dac/ad3552r.c
> > index 97f13c0b9631..b03d3c7cd4c4 100644
> > --- a/drivers/iio/dac/ad3552r.c
> > +++ b/drivers/iio/dac/ad3552r.c
> > @@ -770,7 +770,7 @@ static void
> ad3552r_calc_gain_and_offset(struct ad3552r_desc *dac, s32 ch)
> >  	dac->ch_data[ch].scale_dec = DIV_ROUND_CLOSEST((s64)rem
> * 1000000,
> >  							65536);
> >
> > -	dac->ch_data[ch].offset_int = div_s64_rem(v_min * 65536,
> span, &rem);
> > +	dac->ch_data[ch].offset_int = div_s64_rem(v_min * 65536L,
> span, &rem);
> 
> "v_min" is relatively close to zero on a number line so this can't
> overflow.  There is no way that this change affects anything at runtime
> (except making the code a tiny tiny bit slower).
> 
> And it should be 65536LL for 32 bit systems?
>

If I'm not missing nothing obvious, 65536LL is the right thing to do...
I did not really checked, but if v_min * 65536 can never overflow, 
then yeah, this is not really "fixing" nothing.

- Nuno Sá