svn commit: r265367 - head/lib/libc/regex
imp at bsdimp.com
Mon May 5 22:59:14 UTC 2014
On May 5, 2014, at 3:43 PM, David Chisnall <theraven at FreeBSD.org> wrote:
> On 5 May 2014, at 22:33, Warner Losh <imp at bsdimp.com> wrote:
>> The reallocf() function is identical to the realloc() function, except
>> that it will free the passed pointer when the requested memory cannot be
>> allocated. This is a FreeBSD specific API designed to ease the problems
>> with traditional coding styles for realloc() causing memory leaks in
>> The reallocf() function first appeared in FreeBSD 3.0.
> While reallocf() is nice, it doesn't address the problem of overflow. It takes a single size, forcing the caller to do the number-of-elements * element-size multiplication, which is the problematic one. If an attacker can control the number of elements, then it's possible to make the multiplication overflow so reallocf() will return a valid pointer to an area of memory that is much smaller than the caller was expecting.
Stupid is as stupid does. malloc and realloc both have this same issue. While an interesting theoretical attack, the size doesn’t necessarily come from multiplication. Careful coding is still required, not matter what spin you put on this. reallocf() solves the memory leak issue, but not the problem with overflow (which the realloc() interface has too). The caller can check to make sure they aren’t requesting too much memory and overflowing. The interface isn’t designed to solve the problem you are complaining about.
There’s only so much you can do to prevent programming errors. calloc() isn’t going to solve the world’s problems for you, and introduces a non-trivial amount of overhead for the trivial amount of overhead that is “saved” by moving the overflow check from the caller to the callee...
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
More information about the svn-src-head