Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 20 Jun 2012 09:30:53 +0200
From: Szabolcs Nagy <nsz@...t70.net>
To: musl@...ts.openwall.com
Subject: Re: Re: musl, printf out-of-memory test

* Rich Felker <dalias@...ifal.cx> [2012-06-19 21:52:49 -0400]:
> On Tue, Jun 19, 2012 at 11:17:33PM +0200, Bruno Haible wrote:
> > Hope this helps.
> 
> Yes, it helped a lot. Thanks! The problem was an obscure
> pointer-arithmetic overflow that could only happen in 32-bit binaries
> running on a 64-bit kernel where the stack pointer is near the 4GB
> boundary. This is why I couldn't reproduce it: I'm on a 32-bit
> kernel where the stack is at 3GB and there's no way an offset bounded
> by INT_MAX/9 could reach past 4GB. That's my excuse for why it was
> never noticed before, but it still doesn't justify the bug, which is a
> nasty instance of UB (pointer arithmetic outside array bounds).
> 
> Anyway, it's fixed now.
> 

you mentioned another potential out of bound pointer arithmetics there
but it's not yet fixed:

diff --git a/src/stdio/vfprintf.c b/src/stdio/vfprintf.c
index a3bf18d..116e1ce 100644
--- a/src/stdio/vfprintf.c
+++ b/src/stdio/vfprintf.c
@@ -319,7 +319,7 @@ static int fmt_fp(FILE *f, long double y, int w, int p, int fl, int t)
        if (j < 9*(z-r-1)) {
                uint32_t x;
                /* We avoid C's broken division of negative numbers */
-               d = r + 1 + (j+9*LDBL_MAX_EXP)/9 - LDBL_MAX_EXP;
+               d = r + 1 + ((j+9*LDBL_MAX_EXP)/9 - LDBL_MAX_EXP);
                j += 9*LDBL_MAX_EXP;
                j %= 9;
                for (i=10, j++; j<9; i*=10, j++);

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.