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] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZwlvJCxdiRqRWu6Z@vamoirid-laptop>
Date: Fri, 11 Oct 2024 20:32:04 +0200
From: Vasileios Aoiridis <vassilisamir@...il.com>
To: Javier Carrasco <javier.carrasco.cruz@...il.com>
Cc: "Yo-Jung (Leo) Lin" <0xff07@...il.com>,
	linux-kernel-mentees@...ts.linuxfoundation.org,
	ricardo@...liere.net, skhan@...uxfoundation.org,
	Jonathan Cameron <jic23@...nel.org>,
	Lars-Peter Clausen <lars@...afoo.de>,
	Nathan Chancellor <nathan@...nel.org>,
	Nick Desaulniers <ndesaulniers@...gle.com>,
	Bill Wendling <morbo@...gle.com>,
	Justin Stitt <justinstitt@...gle.com>,
	Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
	Angel Iglesias <ang.iglesiasg@...il.com>,
	Adam Rizkalla <ajarizzo@...il.com>, linux-iio@...r.kernel.org,
	linux-kernel@...r.kernel.org, llvm@...ts.linux.dev
Subject: Re: [PATCH v2] iio: Fix uninitialized variable

On Fri, Oct 11, 2024 at 02:31:00PM +0200, Javier Carrasco wrote:
> On 11/10/2024 13:52, Yo-Jung (Leo) Lin wrote:
> > clang found that the "offset" in bmp580_trigger_handler doesn't get
> > initialized before access. Add proper initialization to this variable.
> > 
> > Signed-off-by: Yo-Jung (Leo) Lin <0xff07@...il.com>
> > ---
> > Change in v2:
> > - Make value initialization immediate before its first use.
> > - Link to v1: https://lore.kernel.org/all/20241011093752.30685-1-0xff07@gmail.com/
> > 
> > ---
> >  drivers/iio/pressure/bmp280-core.c | 2 ++
> >  1 file changed, 2 insertions(+)
> > 
> > diff --git a/drivers/iio/pressure/bmp280-core.c b/drivers/iio/pressure/bmp280-core.c
> > index f4df222ed0c3..682329f81886 100644
> > --- a/drivers/iio/pressure/bmp280-core.c
> > +++ b/drivers/iio/pressure/bmp280-core.c
> > @@ -2222,6 +2222,8 @@ static irqreturn_t bmp580_trigger_handler(int irq, void *p)
> >  		goto out;
> >  	}
> >  
> > +	offset = 0;
> > +
> >  	/* Pressure calculations */
> >  	memcpy(&data->sensor_data[offset], &data->buf[3], 3);
> >  
> 
> That was a quick reply. I would recommend you to wait a little bit while
> the first version is under discussion.
> 
> I still see the offset thing a bit weird. data->sensor_data uses an
> offset to avoid hard-coded numbers, but for data->buf we do exactly
> that, in the very same lines.
> 
> Setting offset to 0 to access the first element i.e. no offset required,
> and then adding the actual offset sizeof(s32), which could even be a
> const if the first access was to sensor_data[0], looks to verbose.
> 
> These things are of course not critical, and the proposed fix is
> definitely ok, but I am missing some consistency here.

Hi everyone!

So if you check also the conversations that we had here [1] and in the
previous versions, indeed the idea behind the offset is to use it as an
self-explanatory index to a char buffer that holds in fact s32 variables.

The data->buf here holds the values that have just been read from the
sensor. If you check on the channel specification of this sensor,
you will see ".realbits = 24" in both values that the sensor returns so
hence the value 3.

I am not sure if it makes sense to use a macro here for each one of the
3's that are going to be used only one time each and in order to be more
"consistent". But I might have a wrong view on this one so feel free to
correct me!

For the initialization of the offset indeed, it was already mentioned
here [2] this morning, but on a different patch!!! I couldn't get this
error though with gcc...

Cheers,
Vasilis

[1]: https://lore.kernel.org/all/20240930202353.38203-3-vassilisamir@gmail.com/
[2]: https://lore.kernel.org/linux-iio/202410111221.YIeXHxOv-lkp@intel.com/



Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ