Re: operator new[] overflow checking in G++

[Kurt Seifried <kseifried () redhat com>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 08/31/2012 06:51 AM, Florian Weimer wrote:
> Last week, I was finally able to fix the operator new[] overflow in gcc
> trunk:
>
>   <http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19351>
>
> This version rejects any attempt to allocate an array of variable-length
> arrays, thus avoiding a variable-times-variable multiplication, for
> which the overflow check was deemed too costly in previous discussions
> with GCC developers.  Variable-length arrays are a GCC extension carried
> over from C++ mode.
>
> The nature of this fix requires that affected software is recompiled—the
> multiplication which needs checking is inside code generated by the
> compiler.  Looking exclusively at referenced symbols, it is not possible
> to check if a C++ program uses operator new[].  (Most don't, std::vector
> is not affected.)
>
> There is another patch which touches code which is not actually used by
> GCC, but could theoretically be called by code emitted by other compilers:
>
>   <http://gcc.gnu.org/ml/gcc-patches/2012-08/msg01416.html>
>
> We're working on a backport of the patch to GCC 4.7:
>
>   <https://bugzilla.redhat.com/show_bug.cgi?id=850911>
>
> This patch will not reject previously accepted programs.  The current
> version does not check for overflow in the array-of-VLAs case, but we
> might still change this.
>
> Additional testing for both versions of the patch is welcome.
>
> PS: If this receives a CVE, it will need one from 2002:
> <http://cert.uni-stuttgart.de/ticker/advisories/calloc.html>

It's never to late. Please use CVE-2002-2439 for this issue.

- -- 
Kurt Seifried Red Hat Security Response Team (SRT)
PGP: 0x5E267993 A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iQIcBAEBAgAGBQJQQS62AAoJEBYNRVNeJnmTA9UQALCIFOSg15SGtzqW7SH9HPi/
Y2cItOvashTCieLAULD1BrtmbMAm9Ltiqfk7EQnvLwsBcmr+IoVfLePzTm1I8SQo
nix9LLZBpmRqKzMwbJYpP3gb5h73Nuf6eJLhZA8cwCX9j9mJ4AVIfyoiuR4B4YKl
qcCu3f7fhrfAFTpuNecw9ebNHZPMXcjNM6UVrP1QsvVjHp8cpX9SYjm/KEDpJRDA
v2eri2v6fPonYJRI5x/Czqa4URakw/ybCkIgARfWPr7pXi0xban5L/ct0Bg3kOEK
uMyM6egWhe29ssAqiHUUY3TuUYKitKy1XoM8uAkZpV3Q36e2eB2klYT4fslL6D75
tiVLWOFtomyWHQRProA5ZOEcNX5pz60A+26AdWCcDXt6vnRAhALyB/fQeb+k+P/s
tcrIhS1AZtQn0uNO0zM59JxzAVAWnU4oRhOop9cOxgS1pd+U6afpFY+9Bt09Dhpx
Lhal2SvILdKEA19HTtfwDHbULhsZhZVbAkUfXM2LXKIsRQblEIcWrWyktrcFZVE+
b9bQ85YyAI07Oug9Ss46RWkXx6f2SOcMCzPCMAzJRpAAPyKQ50UeD0c8yHfTcOTC
MgKqTfW7miwKMNte0Z7rAKJ+tAXvCavelEi5YtP20OnFkMGQ+xqH6l4gI7a/Hau0
NEO5wceDmSmyEzKif8wP
=qkaS
-----END PGP SIGNATURE-----