linux-kernel - Re: [PATCH] iio: adc: mt6360: strengthen return check of mt6360_adc_read

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:   Sun, 27 Feb 2022 17:57:01 +0000
From:   Jonathan Cameron <jic23@...nel.org>
To:     Christophe JAILLET <christophe.jaillet@...adoo.fr>
Cc:     lars@...afoo.de, matthias.bgg@...il.com, nathan@...nel.org,
        ndesaulniers@...gle.com, linus.walleij@...aro.org,
        ardeleanalex@...il.com, Tom Rix <trix@...hat.com>,
        linux-iio@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
        linux-mediatek@...ts.infradead.org, linux-kernel@...r.kernel.org,
        llvm@...ts.linux.dev
Subject: Re: [PATCH] iio: adc: mt6360: strengthen return check of
 mt6360_adc_read_channel

On Sun, 27 Feb 2022 18:01:47 +0100
Christophe JAILLET <christophe.jaillet@...adoo.fr> wrote:

> Le 27/02/2022 à 17:43, trix-H+wXaHxf7aLQT0dZR+AlfA@...lic.gmane.org a 
> écrit :
> > From: Tom Rix <trix-H+wXaHxf7aLQT0dZR+AlfA@...lic.gmane.org>
> > 
> > Clang static analysis reports this issue
> > mt6360-adc.c:277:20: warning: Assigned value is
> >    garbage or undefined
> >    data.values[i++] = val;
> >                     ^ ~~~
> > 
> > val is set by a successful call to m6360_adc_read_channel().
> > A negative return is checked but within m6360_adc_read_channel,
> > a non zero check is done.
> > Strengthen the check to non zero.  
> 
> Hi, my understanding of m6360_adc_read_channel() is that on success, it 
> returns IIO_VAL_INT (i.e. 1).
> 
> So, I think that with your patch, we will now always fail because 'ret' 
> is never 0 at this point.

Firstly I'm glad you were more awake than me Christophe as I missed that
entirely. :(

So two ways we could deal with the warning (which is valid given there
is no way clang could sensibly tell that all those if (ret) actually
mean if (ret < 0).

I don't like changing them to if (ret < 0) inside _adc_read_channel()
because generally it ends up cleaner to just do if (ret) based handling
for regmap calls.  So we could just assign a default to val that is never
used or we could change that function to return 0 on success and adjust
the other call site to return IIO_VAL_INT if there isn't an error.

The second one would make the other caller rather messier so I'd suggest
just giving val a default and adding a comment saying it's for warning
suppression purposes...

Jonathan


> 
> CJ
> 
> > 
> > Signed-off-by: Tom Rix <trix-H+wXaHxf7aLQT0dZR+AlfA@...lic.gmane.org>
> > ---
> >   drivers/iio/adc/mt6360-adc.c | 2 +-
> >   1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/drivers/iio/adc/mt6360-adc.c b/drivers/iio/adc/mt6360-adc.c
> > index 07c0e67683910..9fb6dc305a392 100644
> > --- a/drivers/iio/adc/mt6360-adc.c
> > +++ b/drivers/iio/adc/mt6360-adc.c
> > @@ -269,7 +269,7 @@ static irqreturn_t mt6360_adc_trigger_handler(int irq, void *p)
> >   	memset(&data, 0, sizeof(data));
> >   	for_each_set_bit(bit, indio_dev->active_scan_mask, indio_dev->masklength) {
> >   		ret = mt6360_adc_read_channel(mad, bit, &val);
> > -		if (ret < 0) {
> > +		if (ret) {
> >   			dev_warn(&indio_dev->dev, "Failed to get channel %d conversion val\n", bit);
> >   			goto out;
> >   		}  
>