Re: [PATCH v2 1/2] stdio-common: Use reallocarray for wide strings in vfscanf (bug 34531)

Florian Weimer <[email protected]> writes:

> This avoids theoretical integer overflow issues on 32-bit
> architectures.  The overflow is not reachable since glibc 2.30
> because doubling reaches a size larger than PTRDIFF_MAX, at which
> point realloc fails due to commit 9bf8e29ca136094f73f6 ("malloc:
> make malloc fail with requests larger than PTRDIFF_MAX (BZ#23741)").
> The non-doubling path is used instead.  Eventually, the size
> increments also pass PTRDIFF_MAX, so the fallback realloc fails, too.
> This means that in current glibc, there is no crash.
> ---
> v2: Typo fixes, bug reference.
>  stdio-common/vfscanf-internal.c | 77 +++++++++++++++++----------------
>  1 file changed, 39 insertions(+), 38 deletions(-)

Looks good to me. I've been doing this as well even when the overflows
aren't possible in practice, see a recent coreutils commit [1]. It is
easier to change it and not need to think about whether it is possible
or not in the future.

> @@ -1305,15 +1305,15 @@ __vfscanf_internal (FILE *s, const char *format, va_list argptr,
>  			/* Enlarge the buffer.  */
>  			size_t newsize = grow_to_fit (strsize, width);
>  
> -			wstr = (wchar_t *) realloc (
> -			    *strptr, newsize * sizeof (wchar_t));
> +			wstr = (wchar_t *) __libc_reallocarray
> +			  (*strptr, newsize, sizeof (wchar_t));

I'd probably do "#define reallocarray __libc_reallocarray" since the
symbol can get a bit ugly in places due to its length. But I see we do a
mix, generally depending on whether the code is shared, so I let you
decide. This patch is fine either way.

Reviewed-by: Collin Funk <[email protected]>

Thanks,
Collin

[1] https://lists.gnu.org/archive/html/coreutils/2026-08/msg00057.html