|
|
Message-ID: <4fa294bc-951d-4509-9cc6-47505a72d4ac@gmail.com>
Date: Tue, 21 Jul 2026 22:33:08 -0400
From: Demi Marie Obenour <demiobenour@...il.com>
To: musl@...ts.openwall.com, Rich Felker <dalias@...c.org>,
Luca Kellermann <mailto.luca.kellermann@...il.com>
Subject: Re: [PATCH] sprintf: fix one byte truncation when producing
string of length INT_MAX
On 7/21/26 18:28, Rich Felker wrote:
> On Tue, Jul 21, 2026 at 10:31:04PM +0200, Luca Kellermann wrote:
>> (v)sprint() is supposed to return the number of bytes written to s,
>> excluding the terminating null byte. however, when these functions
>> return INT_MAX, only INT_MAX - 1 bytes (excluding the terminating null
>> byte) are written.
>>
>> this is caused by the way vsprintf() is implemented: calling
>> vsnprintf() with n = INT_MAX. vsnprintf() returns the number of bytes
>> that would be written to s had n been sufficiently large excluding the
>> terminating null byte. output bytes beyond the n-1st are discarded.
>>
>> to accommodate the largest strings (v)sprintf() can produce (length
>> INT_MAX, the return value is of type int), vsnprintf() has to be
>> called with n >= INT_MAX + 1.
>>
>> calling vsnprintf() with n > INT_MAX is possible since commit
>> 11fb383275d20f5f94c00425bd888a02ecbd218e.
>
> Thanks. Indeed, prior to this commit, there was no way for [v]sprintf
> to handle this case right, since vsnprintf would reject the larger
> size.
>
> On 32-bit archs there was never a bug here, because objects of size
> larger than INT_MAX can't exist. But indeed your test case
> demonstrates the problem on 64-bit.
>
> Rich
What does [v]snprintf do if the output would legitimately overflow
INT_MAX?
--
Sincerely,
Demi Marie Obenour (she/her/hers)
Download attachment "OpenPGP_signature.asc" of type "application/pgp-signature" (834 bytes)
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.