Potential integer underflow in `format_converter()` when `precision < 0` and `adjust_precision == true`

[PavlNekrasov]

Description

Hi,

In the following code, possible precision variable value being set to -1 and adjust_precision == true:

php-src/main/snprintf.c

Lines 576 to 586 in 3a14ce1

	adjust_precision = true;
	fmt++;
	if (isdigit((int)*fmt)) {
	STR_TO_DEC(fmt, precision);
	} else if (*fmt == '*') {
	precision = va_arg(ap, int);
	fmt++;
	if (precision < -1)
	precision = -1;
	} else
	precision = 0;

This can result undefined behavior when precision is later cast to size_t.

php-src/main/snprintf.c

Line 845 in 3a14ce1

if (adjust_precision && (size_t)precision < s_len) {

Found by Linux Verification Center (linuxtesting.org) with SVACE.
Reporter: Pavel Nekrasov (p.nekrasov@fobos-nt.ru).
Organization: Fobos-NT (info@fobos-nt.ru).

PHP Version

PHP 8.3

Operating System

Alt p10

[devnexen]

It is a fine observation, but not sure this code path is actually reached/used by any platform, especially since the switch to C99 (if SVACE works more like cppcheck rather than analysis during build, then it is less surprising). And seems, if I m reading correctly, this bug had been acknowledged already by @derickr

[nielsdos]

How exactly is this undefined behaviour?

[PavlNekrasov]

How exactly is this undefined behaviour?

Sorry, you're right — it's not undefined behavior, but it does cause an underflow when a negative precision is cast to size_t.

[nielsdos]

I think that's the intention.
By setting precision to -1 you enforce that (size_t)precision < s_len will never be true. That means that the string won't be shortened. This seems right.

[PavlNekrasov]

Yes, you're right! Thank you!