Skip site navigation (1)Skip section navigation (2)
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

--Apple-Mail=_500DE851-7984-4064-8FC1-CACBF83B04B3
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252


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:
>=20
>> 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.
>=20
> 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. =20=


Stupid is as stupid does. malloc and realloc both have this same issue. =
While an interesting theoretical attack, the size doesn=92t 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=92t requesting too much =
memory and overflowing. The interface isn=92t designed to solve the =
problem you are complaining about.

There=92s only so much you can do to prevent programming errors. =
calloc() isn=92t going to solve the world=92s problems for you, and =
introduces a non-trivial amount of overhead for the trivial amount of =
overhead that is =93saved=94 by moving the overflow check from the =
caller to the callee...

Warner


--Apple-Mail=_500DE851-7984-4064-8FC1-CACBF83B04B3
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

-----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-----

--Apple-Mail=_500DE851-7984-4064-8FC1-CACBF83B04B3--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AFF177D5-AA37-4079-A272-F62FDB608495>