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 <[email protected]>
---
Cc: Jonathan Cameron <[email protected]>
Cc: Lars-Peter Clausen <[email protected]>
Cc: "Uwe Kleine-König" <[email protected]>
Cc: Andy Shevchenko <[email protected]>
Cc: "Nuno Sá" <[email protected]>
Cc: [email protected]
---
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. */
+ __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:
--
2.34.1
On Thu, 22 Feb 2024 14:23:39 -0800
Kees Cook <[email protected]> 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.
>
> Link: https://github.com/ClangBuiltLinux/linux/issues/2000 [1]
> Signed-off-by: Kees Cook <[email protected]>
> ---
> Cc: Jonathan Cameron <[email protected]>
> Cc: Lars-Peter Clausen <[email protected]>
> Cc: "Uwe Kleine-K?nig" <[email protected]>
> Cc: Andy Shevchenko <[email protected]>
> Cc: "Nuno S?" <[email protected]>
> Cc: [email protected]
> ---
> 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.
> + __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);
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.
> iio_push_to_buffers(indio_dev, tmp_buf);
>
> out:
On Fri, Feb 23, 2024 at 05:09:18PM +0000, Jonathan Cameron wrote:
> On Thu, 22 Feb 2024 14:23:39 -0800
> Kees Cook <[email protected]> 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 <[email protected]>
> > ---
> > Cc: Jonathan Cameron <[email protected]>
> > Cc: Lars-Peter Clausen <[email protected]>
> > Cc: "Uwe Kleine-K?nig" <[email protected]>
> > Cc: Andy Shevchenko <[email protected]>
> > Cc: "Nuno S?" <[email protected]>
> > Cc: [email protected]
> > ---
> > 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
--
Kees Cook
On Fri, 23 Feb 2024 09:14:53 -0800
Kees Cook <[email protected]> wrote:
> On Fri, Feb 23, 2024 at 05:09:18PM +0000, Jonathan Cameron wrote:
> > On Thu, 22 Feb 2024 14:23:39 -0800
> > Kees Cook <[email protected]> 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 <[email protected]>
> > > ---
> > > Cc: Jonathan Cameron <[email protected]>
> > > Cc: Lars-Peter Clausen <[email protected]>
> > > Cc: "Uwe Kleine-K?nig" <[email protected]>
> > > Cc: Andy Shevchenko <[email protected]>
> > > Cc: "Nuno S?" <[email protected]>
> > > Cc: [email protected]
> > > ---
> > > 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.
Without the available mask that is a little fiddly you'll have
deal with channel 0 only enabled, channel 1 only enabled and
both channels 0 and channel 1 enabled.
Not too bad though as only 2 channels.
>
> >
> > > + __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?
Ideally it wouldn't check them - the hardwork has been done to read both
channels anyway and the IIO core handles userspace or in kernel consumers
that want a subset of what is enabled, but that needs the available_scan_masks
to be set so that the IIO core knows all channels always enabled.
>
> >
> > 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
yeah. Hindsight!
We could add it in an incremental fashion though
iio_push_to_bufs(struct iio_dev *indio_dev, void *buf, size_t buf_len)
with a length parameter. The oddity that is
iio_push_to_buffers_with_timestamp() would benefit here as that needs
a bigger buffer than immediately apparent in the driver and we've
had a few bugs around that over the years.
It would probably be a one way check.
I might have a play and see how useful this would be.
>
> >
> > > iio_push_to_buffers(indio_dev, tmp_buf);
> > >
> > > out:
>
> Thanks for looking at this!
>
> -Kees
>