linux-kernel - Re: [PATCH] iio: imu: adis16480: clean up a condition

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: <20191007141803.GZ22609@kadam>
Date:   Mon, 7 Oct 2019 17:18:03 +0300
From:   Dan Carpenter <dan.carpenter@...cle.com>
To:     Jonathan Cameron <jonathan.cameron@...wei.com>
Cc:     Jonathan Cameron <jic23@...nel.org>,
        "Ardelean, Alexandru" <alexandru.Ardelean@...log.com>,
        "lars@...afoo.de" <lars@...afoo.de>,
        "kernel-janitors@...r.kernel.org" <kernel-janitors@...r.kernel.org>,
        "Popa, Stefan Serban" <StefanSerban.Popa@...log.com>,
        "linux-iio@...r.kernel.org" <linux-iio@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "Hennerich, Michael" <Michael.Hennerich@...log.com>,
        "pmeerw@...erw.net" <pmeerw@...erw.net>,
        "knaack.h@....de" <knaack.h@....de>
Subject: Re: [PATCH] iio: imu: adis16480: clean up a condition

On Mon, Oct 07, 2019 at 10:21:07AM +0100, Jonathan Cameron wrote:
> On Sun, 6 Oct 2019 21:14:40 +0300
> Dan Carpenter <dan.carpenter@...cle.com> wrote:
> 
> > On Sun, Oct 06, 2019 at 09:51:33AM +0100, Jonathan Cameron wrote:
> > > On Thu, 26 Sep 2019 14:36:30 +0300
> > > Dan Carpenter <dan.carpenter@...cle.com> wrote:
> > >   
> > > > On Thu, Sep 26, 2019 at 11:06:39AM +0000, Ardelean, Alexandru wrote:  
> > > > > On Thu, 2019-09-26 at 11:10 +0300, Dan Carpenter wrote:    
> > > > > > [External]
> > > > > > 
> > > > > > The "t" variable is unsigned so it can't be less than zero.  We really
> > > > > > are just trying to prevent divide by zero bugs so just checking against
> > > > > > zero is sufficient.  
> > > 
> > > I'm not sure that true.  It if were signed we'd be detecting that the
> > > input from userspace was negative.  
> > 
> > It does a really bad job of that though so it raises more questions than
> > answers.  Maybe just one of the parameters is negative or maybe the
> > multiply or the addition overflowed?  Should scenarios those be checked?
> > 
> > It turns out none of those situations matter, only divide by zero needs
> > to be checked.
> 
> It isn't being nearly paranoid enough. Either val or val2 being
> negative is a reason to fault out.  Divide by zero needs handling after
> that.  Obviously divide by zero is the only one that causes a crash but
> negatives are going to cause rather 'unexpected' results.

The result is that it gets capped at st->chip_info->max_dec_rate so it's
not a horrible result.  :P  I don't know if it's unexpected or not.

regards,
dan carpenter