[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120620073053.GX17860@port70.net>
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.
