From owner-svn-src-all@FreeBSD.ORG Mon May 5 22:59:09 2014 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 27D52D5E for ; Mon, 5 May 2014 22:59:09 +0000 (UTC) Received: from mail-pa0-f50.google.com (mail-pa0-f50.google.com [209.85.220.50]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E3762EAD for ; Mon, 5 May 2014 22:59:08 +0000 (UTC) Received: by mail-pa0-f50.google.com with SMTP id fb1so3233789pad.9 for ; Mon, 05 May 2014 15:59:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=j3+niS88DzaJcqJ97FcWhesEAOpY/nDr68oRtu+lF9U=; b=eRgw1BfPEYqQ4LSI0Pk/PlnYWLiSZgCRGISXLb8jl318V46HYdkWOno5B2yzjY7W0O pSgiMaRjeCZlTauujHVZwFyM8dq4s0XbVzdex6W72f9jGd8PoIHt7Aa6P6kh3yvmILP7 qEVRHlO9bcLupMihcexI1JWwvbQOfCwKT8n9c/gi9f0wpjbXnq38fR7hHOmJ2JzVAADd rrefvsRifKfh3Mc0G0L/RB38uv702Xyil6RwE5n8wW8SXoMKvsDxPLMKBJ2VFikOTy+I 9Jml+pBTmWINBh75yemdT8sssJKX2IaNmP7nM2k3j48iaSznMa6UyGHUvWNG/udrITJF HJaQ== X-Gm-Message-State: ALoCoQkCfGtm+eIKUYMsN2MFLH3hjdj3ervri+vtL0yJzSipsFxXxmanJwLErmZUKUQOgPUMI+cq X-Received: by 10.66.197.135 with SMTP id iu7mr76221575pac.149.1399330747906; Mon, 05 May 2014 15:59:07 -0700 (PDT) Received: from [10.64.26.239] (dc1-prod.netflix.com. [69.53.236.251]) by mx.google.com with ESMTPSA id g6sm81526059pat.2.2014.05.05.15.59.05 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 05 May 2014 15:59:06 -0700 (PDT) Sender: Warner Losh Content-Type: multipart/signed; boundary="Apple-Mail=_500DE851-7984-4064-8FC1-CACBF83B04B3"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: svn commit: r265367 - head/lib/libc/regex From: Warner Losh In-Reply-To: Date: Mon, 5 May 2014 16:59:03 -0600 Message-Id: References: <201405051641.s45GfFje086423@svn.freebsd.org> <5367CD77.40909@freebsd.org> <5367EB54.1080109@FreeBSD.org> <3C7CFFB7-5C84-4AC1-9A81-C718D184E87B@FreeBSD.org> <7D7A417E-17C3-4001-8E79-0B57636A70E1@gmail.com> To: David Chisnall X-Mailer: Apple Mail (2.1874) Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, Pedro Giffuni , Andrey Chernov , src-committers X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2014 22:59:09 -0000 --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 wrote: > On 5 May 2014, at 22:33, Warner Losh 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--