linux-kernel - Re: [PATCH] iioc: dac: ltc2664: Fix span variable usage in ltc2664_channel

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] [day] [month] [year] [list]

Message-ID: <20241005173443.4a34fb73@jic23-huawei>
Date: Sat, 5 Oct 2024 17:34:43 +0100
From: Jonathan Cameron <jic23@...nel.org>
To: Mohammed Anees <pvmohammedanees2003@...il.com>
Cc: linux-iio@...r.kernel.org, linux-kernel@...r.kernel.org, Michael
 Hennerich <michael.hennerich@...log.com>, Kim Seer Paller
 <kimseer.paller@...log.com>, Lars-Peter Clausen <lars@...afoo.de>
Subject: Re: [PATCH] iioc: dac: ltc2664: Fix span variable usage in
 ltc2664_channel_config function

On Fri,  4 Oct 2024 19:24:54 +0530
Mohammed Anees <pvmohammedanees2003@...il.com> wrote:

> In the current implementation of the ltc2664_channel_config function,
> a variable named span is declared and initialized to 0, intended to
> capture the return value of the ltc2664_set_span function. However,
> the output of ltc2664_set_span is directly assigned to chan->span,
> leaving span unchanged. As a result, when the function later checks
> if (span < 0), this condition will never trigger an error since
> span remains 0, this flaw leads to ineffective error handling. The
> current patch resolves this issue by checking chan->span rather than
> span and also effectively removing span variable.
> 
> Signed-off-by: Mohammed Anees <pvmohammedanees2003@...il.com>
Good catch, but needs a Fixes tag.

Also, slight preference for using ret and assigning on success.
Ideal is not to have side effects when an error occurs,
though I'd imagine in this case we fail the probe so it doesn't
matter and in such cases it's not a hard requirement.

> ---
>  drivers/iio/dac/ltc2664.c | 10 +++++-----
>  1 file changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/iio/dac/ltc2664.c b/drivers/iio/dac/ltc2664.c
> index 5be5345ac5c8..64c8a51aad81 100644
> --- a/drivers/iio/dac/ltc2664.c
> +++ b/drivers/iio/dac/ltc2664.c
> @@ -516,7 +516,7 @@ static int ltc2664_channel_config(struct ltc2664_state *st)
>  	const struct ltc2664_chip_info *chip_info = st->chip_info;
>  	struct device *dev = &st->spi->dev;
>  	u32 reg, tmp[2], mspan;
> -	int ret, span = 0;
> +	int ret;
>  
>  	mspan = LTC2664_MSPAN_SOFTSPAN;
>  	ret = device_property_read_u32(dev, "adi,manual-span-operation-config",
> @@ -581,8 +581,8 @@ static int ltc2664_channel_config(struct ltc2664_state *st)
>  		if (!ret && mspan == LTC2664_MSPAN_SOFTSPAN) {
>  			chan->span = ltc2664_set_span(st, tmp[0] / 1000,
>  						      tmp[1] / 1000, reg);
I'd slightly prefer
			ret =....
			if (ret < 0)
				...
			chan->span = ret;

etc

> -			if (span < 0)
> -				return dev_err_probe(dev, span,
> +			if (chan->span < 0)
> +				return dev_err_probe(dev, chan->span,
>  						     "Failed to set span\n");
>  		}
>  
> @@ -590,8 +590,8 @@ static int ltc2664_channel_config(struct ltc2664_state *st)
>  						     tmp, ARRAY_SIZE(tmp));
>  		if (!ret) {
>  			chan->span = ltc2664_set_span(st, 0, tmp[1] / 1000, reg);
> -			if (span < 0)
> -				return dev_err_probe(dev, span,
similar down here.
> +			if (chan->span < 0)
> +				return dev_err_probe(dev, chan->span,
>  						     "Failed to set span\n");
>  		}
>  	}