![]() |
|
Message-ID: <20250920014444.GA1827@brightrain.aerifal.cx> Date: Fri, 19 Sep 2025 21:44:44 -0400 From: Rich Felker <dalias@...c.org> To: Demi Marie Obenour <demiobenour@...il.com> Cc: musl@...ts.openwall.com, Georg Kotheimer <georg.kotheimer@...nkonzept.com> Subject: Re: Bug: Stack buffer overflow in printf on aarch64 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. Rich
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.