[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <cc10ecb1-a2a2-47df-b3db-75672b38b6fe@gmail.com>
Date: Sat, 20 Sep 2025 14:38:22 -0400
From: Demi Marie Obenour <demiobenour@...il.com>
To: Rich Felker <dalias@...c.org>
Cc: musl@...ts.openwall.com, Georg Kotheimer <georg.kotheimer@...nkonzept.com>
Subject: Re: Bug: Stack buffer overflow in printf on aarch64
On 9/19/25 21:44, Rich Felker wrote:
> On Fri, Sep 19, 2025 at 08:18:04PM -0400, Demi Marie Obenour wrote:
>> 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?
>
> From the proposed commit description:
>
> this bug has not been present in any release, and has not been
> analyzed in depth for security considerations.
>
> It's only present in a range of git-master.
Oh, then it is not a security issue. Sorry!
That's what I get for reading the mailing list
without looking at the git repository.
--
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.
