diff mbox series

[RFC] iio: pressure: dlhl60d: Check mask_width for IRQs

Message ID 20240222222335.work.759-kees@kernel.org
State New
Headers
Series [RFC] iio: pressure: dlhl60d: Check mask_width for IRQs |

Commit Message

Kees Cook Feb. 22, 2024, 10:23 p.m. UTC 
  Clang tripped over a FORTIFY warning in this code, and while it seems it
may be a false positive in Clang due to loop unwinding, the code in
question seems to make a lot of assumptions. Comments added, and the
Clang warning[1] has been worked around by growing the array size.
Also there was an uninitialized 4th byte in the __be32 array that was
being sent through to iio_push_to_buffers().

Link: https://github.com/ClangBuiltLinux/linux/issues/2000 [1]
Signed-off-by: Kees Cook <keescook@chromium.org>
---
Cc: Jonathan Cameron <jic23@kernel.org>
Cc: Lars-Peter Clausen <lars@metafoo.de>
Cc: "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>
Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: "Nuno Sá" <nuno.sa@analog.com>
Cc: linux-iio@vger.kernel.org
---
 drivers/iio/pressure/dlhl60d.c | 11 +++++++++--
 1 file changed, 9 insertions(+), 2 deletions(-)

Comments

Kees Cook Feb. 23, 2024, 5:14 p.m. UTC | #1 
On Fri, Feb 23, 2024 at 05:09:18PM +0000, Jonathan Cameron wrote:
> On Thu, 22 Feb 2024 14:23:39 -0800
> Kees Cook <keescook@chromium.org> wrote:
> 
> > Clang tripped over a FORTIFY warning in this code, and while it seems it
> > may be a false positive in Clang due to loop unwinding, the code in
> > question seems to make a lot of assumptions. 
> 
> Hi Kees,
> 
> The assumptions are mostly characteristics of how the IIO buffers work
> with the scan masks defined based on indexes in the driver provided
> struct iio_chan_spec arrays.
> 
> This driver is doing more work than it should need to as we long ago
> moved some of the more fiddly handling into the IIO core.
> 
> > Comments added, and the
> > Clang warning[1] has been worked around by growing the array size.
> > Also there was an uninitialized 4th byte in the __be32 array that was
> > being sent through to iio_push_to_buffers().
> 
> That is indeed not good - the buffer should have been zero initialized.

Okay, I'll get this respun and include the fix.

> 
> > 
> > Link: https://github.com/ClangBuiltLinux/linux/issues/2000 [1]
> > Signed-off-by: Kees Cook <keescook@chromium.org>
> > ---
> > Cc: Jonathan Cameron <jic23@kernel.org>
> > Cc: Lars-Peter Clausen <lars@metafoo.de>
> > Cc: "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>
> > Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> > Cc: "Nuno Sá" <nuno.sa@analog.com>
> > Cc: linux-iio@vger.kernel.org
> > ---
> >  drivers/iio/pressure/dlhl60d.c | 11 +++++++++--
> >  1 file changed, 9 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/iio/pressure/dlhl60d.c b/drivers/iio/pressure/dlhl60d.c
> > index 28c8269ba65d..9bbecd0bfe88 100644
> > --- a/drivers/iio/pressure/dlhl60d.c
> > +++ b/drivers/iio/pressure/dlhl60d.c
> > @@ -250,20 +250,27 @@ static irqreturn_t dlh_trigger_handler(int irq, void *private)
> >  	struct dlh_state *st = iio_priv(indio_dev);
> >  	int ret;
> >  	unsigned int chn, i = 0;
> > -	__be32 tmp_buf[2];
> > +	/* This was only an array pair of 4 bytes. */
> 
> True, which is the right size as far as I can tell.
> If we need this to suppress a warning then comment should say that.

Okay. I think I'll leave it as 2 and manually "unroll" the loop.

> 
> > +	__be32 tmp_buf[4] = { };
> >  
> >  	ret = dlh_start_capture_and_read(st);
> >  	if (ret)
> >  		goto out;
> >  
> > +	/* Nothing was checking masklength vs ARRAY_SIZE(tmp_buf)? */
> 
> Not needed but no way a compiler could know that.
> 
> > +	if (WARN_ON_ONCE(indio_dev->masklength > ARRAY_SIZE(tmp_buf)))
> > +		goto out;
> > +
> >  	for_each_set_bit(chn, indio_dev->active_scan_mask,
> 
> This is all a bit pointless if not 'wrong' other than the
> 4th byte uninitialized part.  The limit can be hard coded as 2 as
> that's a characteristic of this driver.
> 
> For device that always read a particular set of channels they
> should provide indio_dev->available_scan_masks = { BIT(1) | BIT(0), 0 };
> and then always push all the data making this always
> 
> 	memcpy(&tmp_buf[0], &st->rx_buf[1], 3);
> 	mempcy(&tmp_buf[1], &st->rx_buf[1] + 3, 3);

Okay, so this could be unrolled manually to check just for bits 0 and 1?

> 
> The buffer demux code in the IIO core will deal with repacking the data
> if only one channel is enabled.
> 
> >  		indio_dev->masklength) {
> > -		memcpy(tmp_buf + i,
> > +		/* This is copying 3 bytes. What about the 4th? */
> > +		memcpy(&tmp_buf[i],
> >  			&st->rx_buf[1] + chn * DLH_NUM_DATA_BYTES,
> >  			DLH_NUM_DATA_BYTES);
> >  		i++;
> >  	}
> >  
> > +	/* How do we know the iio buffer_list has only 2 items? */
> 
> Can only include items from the channels array at indexes up to the max
> scan_index in there, so 0 and 1 in this case (1 might not be present if only
> one channel is enabled). Sizes (and alignment) are given by storagebits so
> 4 bytes for each.

This code pattern seems repeated through all of iio, so I guess we'll
leave it as-is. It seems like it'd be nice to have a "length" argument
to iio_push_to_buffers(), just to sanity check, but that would need to
be a pretty large patch. :P

> 
> >  	iio_push_to_buffers(indio_dev, tmp_buf);
> >  
> >  out:

Thanks for looking at this!

-Kees
diff mbox series

Patch

diff --git a/drivers/iio/pressure/dlhl60d.c b/drivers/iio/pressure/dlhl60d.c
index 28c8269ba65d..9bbecd0bfe88 100644
--- a/drivers/iio/pressure/dlhl60d.c
+++ b/drivers/iio/pressure/dlhl60d.c
@@ -250,20 +250,27 @@  static irqreturn_t dlh_trigger_handler(int irq, void *private)
 	struct dlh_state *st = iio_priv(indio_dev);
 	int ret;
 	unsigned int chn, i = 0;
-	__be32 tmp_buf[2];
+	/* This was only an array pair of 4 bytes. */
+	__be32 tmp_buf[4] = { };
 
 	ret = dlh_start_capture_and_read(st);
 	if (ret)
 		goto out;
 
+	/* Nothing was checking masklength vs ARRAY_SIZE(tmp_buf)? */
+	if (WARN_ON_ONCE(indio_dev->masklength > ARRAY_SIZE(tmp_buf)))
+		goto out;
+
 	for_each_set_bit(chn, indio_dev->active_scan_mask,
 		indio_dev->masklength) {
-		memcpy(tmp_buf + i,
+		/* This is copying 3 bytes. What about the 4th? */
+		memcpy(&tmp_buf[i],
 			&st->rx_buf[1] + chn * DLH_NUM_DATA_BYTES,
 			DLH_NUM_DATA_BYTES);
 		i++;
 	}
 
+	/* How do we know the iio buffer_list has only 2 items? */
 	iio_push_to_buffers(indio_dev, tmp_buf);
 
 out: