Date: Mon, 5 May 2014 16:59:03 -0600 From: Warner Losh <imp@bsdimp.com> To: David Chisnall <theraven@FreeBSD.org> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, Pedro Giffuni <pfg@FreeBSD.org>, Andrey Chernov <ache@freebsd.org>, src-committers <src-committers@freebsd.org> Subject: Re: svn commit: r265367 - head/lib/libc/regex Message-ID: <AFF177D5-AA37-4079-A272-F62FDB608495@bsdimp.com> In-Reply-To: <A4B5E0E8-93CB-4E80-9065-5D25A007B726@FreeBSD.org> References: <201405051641.s45GfFje086423@svn.freebsd.org> <5367CD77.40909@freebsd.org> <B11B5B25-8E05-4225-93D5-3A607332F19A@FreeBSD.org> <5367EB54.1080109@FreeBSD.org> <3C7CFFB7-5C84-4AC1-9A81-C718D184E87B@FreeBSD.org> <7D7A417E-17C3-4001-8E79-0B57636A70E1@gmail.com> <A4B5E0E8-93CB-4E80-9065-5D25A007B726@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
[-- Attachment #1 --] On May 5, 2014, at 3:43 PM, David Chisnall <theraven@FreeBSD.org> wrote: > On 5 May 2014, at 22:33, Warner Losh <imp@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 [-- Attachment #2 --] -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJTaBe3AAoJEGwc0Sh9sBEARgsQANEtHGWk/H7xDYulO1C8k3de 7gp7Ru73TaE4v9ntXgwnFMwhN0iJ1UPoLNM6CaXpqN2QH6+a21z3xdi+U91d7PON HmQiB4PUIa/NLrGWJlLx5rS0BfKrG5OiA0ezxudptGTNM3fqBbJPGPX95NIfQ2vO Zf+OqgYhSH4aC3xJNQv0D8fjZlKOTbnLsOUdOy0j/KgYZbuBhwusFB3B7xtMwpJf e3UeoA1kiKkO4NlXxft1tSBShJD2Ah0RV7oQswtb78JTDyxON/vHKTAoOF8Adx3B MCyQJ9OxmmQdS9DsUWXIRIpmNdJ5Iz0p+9z3ywAZLEGjZ5Y/hG3E3NIKb+FiOOEx t51GWLkFMKmBcrSvGYD84gw28yeVaaMJNJQ7yMYUIAP4IE3sFQl+urL9ttj9dPow O95W124c9I5OQwPHEVD78eapterGNKIEN5I7NZDfiLt7bisKU4N0xFEy3A+NV36w FVIrOX3q2hAWITrGKogQjk6i63mRdhlTdy9e9cChJQ+zgf2B9xgT9jeNpipdhuXe F5j/deRhaqlMHBX/PyioaymryGRm6zqjYGIFBp+w7UB7pNT7mTIMUS1LJBAVlko0 DUtLIVPr6z1TqTag5pgu6fQxTpNuW1Q5SfgPDS/lsbvqel8YWcDJU+3QeL+lPX7A nGdSYtoddOy98ZoWsP7O =yL9a -----END PGP SIGNATURE-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AFF177D5-AA37-4079-A272-F62FDB608495>