linux-kernel - Re: [PATCH v5 2/8] iio: core: add fixed point parsing with 64-bit parts

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <anhtxco52jz2ktmxlittsjuvfqybwrwgy76bjhni3j5dzx2rh2@hpzf3sfwe7hf>
Date: Mon, 26 Jan 2026 16:55:13 +0000
From: Rodrigo Alencar <455.rodrigo.alencar@...il.com>
To: Andy Shevchenko <andriy.shevchenko@...el.com>, 
	Rodrigo Alencar <455.rodrigo.alencar@...il.com>
Cc: rodrigo.alencar@...log.com, linux-kernel@...r.kernel.org, 
	linux-iio@...r.kernel.org, devicetree@...r.kernel.org, linux-doc@...r.kernel.org, 
	Jonathan Cameron <jic23@...nel.org>, David Lechner <dlechner@...libre.com>, 
	Andy Shevchenko <andy@...nel.org>, Lars-Peter Clausen <lars@...afoo.de>, 
	Michael Hennerich <Michael.Hennerich@...log.com>, Rob Herring <robh@...nel.org>, 
	Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley <conor+dt@...nel.org>, 
	Jonathan Corbet <corbet@....net>
Subject: Re: [PATCH v5 2/8] iio: core: add fixed point parsing with 64-bit
 parts

On 26/01/26 06:07PM, Andy Shevchenko wrote:
> On Mon, Jan 26, 2026 at 03:30:44PM +0000, Rodrigo Alencar wrote:
> > On 26/01/26 03:20PM, Rodrigo Alencar wrote:
> > > On 26/01/26 04:53PM, Andy Shevchenko wrote:
> > > > On Mon, Jan 26, 2026 at 02:26:20PM +0000, Rodrigo Alencar wrote:
> 
> ...
> 
> > > > Why? Can you elaborate how checking amount of digits is different to
> > > > check_mul_overflow()?
> > > 
> > > consider U64_MAX = 18_446_744_073_709_551_615 as the limit:
> > > - 19_000_000_000_000_000_000 contains the same amount of digits but overflows.
> > > - 18_446_744_073_710_000_000 contains the same amount of digits but overflows.
> > > 
> > > to catch those cases, we need to check for the overflow, everytime we read a
> > > character and accumulate:
> > > 
> > > u64 acc;
> > > 
> > > while(isdigit(*str))
> > > 	if (check_mul_overflow(acc, 10, &acc) ||
> > > 	    check_add_overflow(acc, *str - '0', &acc))
> > > 		return -EOVERFLOW;
> > > 
> > > *res = acc;
> > > 
> > > acc can get weird results if not checked. 
> > 
> > Thinking about it again, that check could be done only in the last step
> > (20th for u64)
> 
> Does kstrto*() also perform only last check? I think they do for each
> iteration.

It does the following:

...
		if (unlikely(res & (~0ull << 60))) {
			if (res > div_u64(ULLONG_MAX - val, base))
				rv |= KSTRTOX_OVERFLOW;
		}
...

so overflow is checked when either one of the 4 MSbits are set.

for now, I am thinking of something like:

static ssize_t iio_safe_strtou64(const char *str, const char **endp,
				 size_t max_chars, u64 *result)
{
	u64 digit, acc = 0;
	size_t idx = 0;

	while (isdigit(*str) && idx < max_chars) {
		digit = *str - '0';
		if (unlikely(idx > 19)) {
			if (check_mul_overflow(acc, 10, &acc) ||
			    check_add_overflow(acc, digit, &acc))
				return -EOVERFLOW;
		} else {
			acc = acc * 10 + digit;
		}
		str++;
		idx++;
	}

	*endp = str;
	*result = acc;
	return idx;
}

which would help the truncation when parsing the fractional part
with max_chars, avoiding a div64_u64() to adjust precision:

...
	digit_count = iio_safe_strtou64(str, &end, SIZE_MAX, &i);
	if (digit_count < 0)
		return digit_count;

	if (precision && *end == '.') {
		str = end + 1;
		digit_count = iio_safe_strtou64(str, &end, precision, &f);
		if (digit_count < 0)
			return digit_count;

		if (digit_count < precision) /* scale up */
			f *= int_pow(10, precision - digit_count);

		while (isdigit(*end)) /* truncate */
			end++;
	}
...

but I understand you would not like this approach, because it does not use
simple_strtoull() or kstrtoull(). Problem is simple_strtoull() is not
overflow-safe and kstrtoull() does not allow to track a pointer to end
of the string.

Given that the current implementation of iio_str_to_fixpoint() is not using
simple_strtoull() I am not seeing an issue with this approach.

Kind regards,

Rodrigo Alencar