linux-hardening - Re: [PATCH] [RFC] iio: pressure: dlhl60d: Check mask

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: <20240223170918.00006b16@Huawei.com>
Date: Fri, 23 Feb 2024 17:09:18 +0000
From: Jonathan Cameron <Jonathan.Cameron@...wei.com>
To: Kees Cook <keescook@...omium.org>
CC: Jonathan Cameron <jic23@...nel.org>, Lars-Peter Clausen <lars@...afoo.de>,
	Uwe Kleine-König <u.kleine-koenig@...gutronix.de>, Andy
 Shevchenko <andriy.shevchenko@...ux.intel.com>, Nuno Sá
	<nuno.sa@...log.com>, <linux-iio@...r.kernel.org>, Nathan Chancellor
	<nathan@...nel.org>, Nick Desaulniers <ndesaulniers@...gle.com>, "Bill
 Wendling" <morbo@...gle.com>, Justin Stitt <justinstitt@...gle.com>,
	<linux-kernel@...r.kernel.org>, <llvm@...ts.linux.dev>,
	<linux-hardening@...r.kernel.org>
Subject: Re: [PATCH] [RFC] iio: pressure: dlhl60d: Check mask_width for IRQs

On Thu, 22 Feb 2024 14:23:39 -0800
Kees Cook <keescook@...omium.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.

> 
> Link: https://github.com/ClangBuiltLinux/linux/issues/2000 [1]
> Signed-off-by: Kees Cook <keescook@...omium.org>
> ---
> Cc: Jonathan Cameron <jic23@...nel.org>
> Cc: Lars-Peter Clausen <lars@...afoo.de>
> Cc: "Uwe Kleine-König" <u.kleine-koenig@...gutronix.de>
> Cc: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
> Cc: "Nuno Sá" <nuno.sa@...log.com>
> Cc: linux-iio@...r.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.

> +	__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: