[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <6c5abf1f-7000-46c8-847d-f59745f09caf@kernkonzept.com>
Date: Sat, 20 Sep 2025 14:00:29 +0200
From: Georg Kotheimer <georg.kotheimer@...nkonzept.com>
To: Rich Felker <dalias@...c.org>
Cc: musl@...ts.openwall.com
Subject: Re: Bug: Stack buffer overflow in printf on aarch64
I am not knowledgeable enough to judge whether the math is correct, but
from an empirical point of view the patch looks good, i.e. the overflow
is gone.
Thanks for the explanation and promptly fixing the issue!
On 20.09.25 00: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.
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.
