[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <49438cb3-3dc6-451a-a60b-49c5a34e4f8a@gmail.com>
Date: Fri, 19 Sep 2025 20:18:04 -0400
From: Demi Marie Obenour <demiobenour@...il.com>
To: musl@...ts.openwall.com, Rich Felker <dalias@...c.org>,
Georg Kotheimer <georg.kotheimer@...nkonzept.com>
Subject: Re: Bug: Stack buffer overflow in printf on aarch64
On 9/19/25 18:52, Rich Felker wrote:
> On Fri, Sep 19, 2025 at 06:25:03PM -0400, Rich Felker wrote:
>> On Fri, Sep 19, 2025 at 10:20:54PM +0200, Georg Kotheimer wrote:
>>> Hi,
>>>
>>> now I am a little confused, are you referring to the commit
>>> f96e47a26102d537c29435f0abf9ec94676a030e ("printf: fix regression in
>>> large double formatting on ld128 archs"), which is available on the
>>> master branch? Or are you referring to some internal git that is not
>>> visible to the public?
>>>
>>> Because if it's the former, it seems like the fix is insufficient, as I
>>> just rechecked which commit I had checked out locally, it is
>>> 0b86d60badad6a69b37fc06d18b5763fbbf47b58, which includes the
>>> aforementioned fix. But still I observe the overflow I reported.
>>
>> Thank you so much for finding this. Indeed, the math is incorrect.
>> max_mant_slots is computed as if each slot held at least 29 bits,
>> which would be true if they were being expanded to the left of the
>> radix point. But they're not. The initial y has 29 bits to the left of
>> the radix point, but all the rest are to the right.
>>
>> At each stage of peeling bits, 29 bits are extracted to the next slot
>> in *z, but the multiplication by 1000000000 adds back 21 bits to the
>> mantissa of y. This nets only 8 bits being peeled.
>>
>> And indeed, using the formula 1+(ldbl_mant_dig-29+7)/8, representing 1
>> slot for the initial 29 bits, counting off 29 bits initially peeled,
>> and adding 8 per iteration, gives 12 as an upper bound, which agrees
>> with the empirical result of 11 iterations for your worst-case value.
>>
>> (The upper bound is not sharp because multiplying by 1e9 doesn't
>> actually add a "whole" 21 bits, but some fraction of the last bit.)
>>
>> I'll prepare a proposed patch.
>
> See attached.
Is a new release with the security fix planned?
--
Sincerely,
Demi Marie Obenour (she/her/hers)
Download attachment "OpenPGP_0xB288B55FFF9C22C1.asc" of type "application/pgp-keys" (7141 bytes)
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.
