Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 10 Jan 2016 12:38:53 +0100
From: Markus Wichmann <>
Subject: Re: Possible infinite loop in qsort()

On Sat, Jan 09, 2016 at 11:05:16PM -0500, Rich Felker wrote:
> On Sat, Jan 09, 2016 at 10:07:19AM +0100, Felix Janda wrote:
> > musl enforces that object sizes should not be greater than PTRDIFF_MAX.
> > See for example the discussion at
> > 
> >
> > 
> > So there will not be objects of size 3GB with musl on x32. Since the
> > Leonardo numbers grow slower than 2^n in general no overflow should
> > happen if "size" is valid. Otherwise, UB was invoked.

OK. Might want to make that assumption a bit more prominent, because
this is the first time I've ever heard about it, but OK, no objects >2GB
on 32-bit archs.

> Note also that if you do want to use this code on an implementation
> without such a guarantee, only the case where the member size is 1 can
> possibly have >SIZE_MAX/2 members.

Maybe, but the point was that you can overflow the Leonardo number
calculation for any given width. Re-read the example I gave: It was less
than 900,000,000 ints you needed to overflow the calculation.

What I did was make sure that nel * width is greater than the greatest
Leonardo number * width that's representable in the architecture's
size_t. That is possible for every given width. The inequation I just
gave boils down to nel > max{l | l is Leonardo number, l * width < 2^32}

But since there are (plenty of) Leonardo numbers between 2^31 and 2^32,
and object size (nel * width) is limited to <2^31, with a valid object
the calculation can't overflow. And with an invalid object, I don't know
if the code as given would even work, as pointer differences wouldn't
work. Haven't tested that one, either.


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.