|
Message-ID: <20160110113852.GE2016@debian> Date: Sun, 10 Jan 2016 12:38:53 +0100 From: Markus Wichmann <nullplan@....net> To: musl@...ts.openwall.com 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 > > > > http://www.openwall.com/lists/musl/2013/06/27/7 > > > > 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. Ciao, Markus
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.