On May 5, 2014, at 3:43 PM, David Chisnall <thera...@freebsd.org> wrote:
> On 5 May 2014, at 22:33, Warner Losh <i...@bsdimp.com> wrote: > >> reallocf(): >> 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 >> libraries. >> ... >> 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... Warner
signature.asc
Description: Message signed with OpenPGP using GPGMail
