Re: [PATCH v1 1/1] iio: adc: tsc2046: fix memory corruption by preventing array overflow

[Jonathan Cameron <jic23@kernel.org>]

On Mon, 10 Jan 2022 08:19:45 +0100
Oleksij Rempel <o.rempel@pengutronix.de> wrote:

> Hi Jonathan,
> 
> On Sun, Jan 09, 2022 at 03:25:57PM +0000, Jonathan Cameron wrote:
> > On Fri,  7 Jan 2022 09:14:01 +0100
> > Oleksij Rempel <o.rempel@pengutronix.de> wrote:
> >   
> > > On one side we have indio_dev->num_channels includes all physical channels +
> > > timestamp channel. On other side we have an array allocated only for
> > > physical channels. So, fix memory corruption by ARRAY_SIZE() instead of
> > > num_channels variable.
> > > 
> > > Fixes: 9374e8f5a38d ("iio: adc: add ADC driver for the TI TSC2046 controller")
> > > Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>  
> > Hi Olesij,
> > 
> > Have you managed to make this occur, or is it inspection only?  
> 
> Yes, this bug has eaten my rx_one and tx_one pointers on probe. I wonted
> to use this buffers for read_raw and noticed that they do not exist.

I got hung up on the first case and failed to notice the second one was
entirely different :(

> 
> > I 'think' (it's been a while since I looked at the particular code) that the timestamp
> > bit in active_scan_mask will never actually be set because we handle that as a
> > separate flag.  
> 
> I didn't tested if active_scan_mask will trigger this issue as well, but
> It it looked safer to me, to avoid this issue in both places. Even if on
> of it is only theoretical.

It certainly does no harm to not check a bit that is never set, so I'm fine with
the change - just don't want to have lots of 'fixes' for this in other drivers
adding noise and pointless backports.  This one is fine because we need the
other part of the patch anyway.

Jonathan


> 
> > So it is indeed an efficiency improvement to not check that bit but I don't think
> > it's a bug to do so.  More than possible I'm missing something though!
> > 
> > This one had me quite worried when I first read it because this is a very common
> > pattern to see in IIO drivers.  
> 
> I was thinking about this as well, because big part of this code was
> inspired by other drivers. But i didn't reviewed other places so far.
> 
> Regards,
> Oleksij