It was reported that C++ new[] operator was previously missing integer overflow / wrap around checks for its arguments. If an application compiled with gcc accepted untrusted input for memory allocation and was missing application-level checks for integer overflows of arguments, provided to the new[] operator, an attacker could use this flaw to cause the memory region, allocated in the end for the new[] operator statement, it to be smaller than truly required, possibly leading to heap-based buffer overflows. Upstream bug report: [1] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19351 Upstream patches: [2] http://gcc.gnu.org/ml/gcc-patches/2012-06/msg01689.html [3] http://gcc.gnu.org/ml/gcc-patches/2012-08/msg01416.html References: [4] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35790 [5] http://cert.uni-stuttgart.de/ticker/advisories/calloc.html
This issue affects the versions of the gcc package, as shipped with Fedora release of 16 and 17. Please schedule an update. -- This issue affects the versions of the compat-gcc-34 packages, as shipped with Fedora release of 16 and 17. Please schedule an update.
Created compat-gcc-34 tracking bugs for this issue Affects: fedora-all [bug 853919]
Created gcc tracking bugs for this issue Affects: fedora-all [bug 853918]
Reproducer (from http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19351#c0): ----------------------------------------------------------------------- #include <testsuite_hooks.h> struct foo { char data[16]; void* operator new[] (size_t size) { VERIFY(size != sizeof(foo)); VERIFY (false); return malloc(size); } }; int main() { size_t size = size_t (-1) / sizeof(foo) + 2; try { foo* f = new foo[size]; VERIFY (f == 0); VERIFY (false); } catch(std::bad_alloc&) { return 0; } }
I'm going to close this bug. It's fixed upstream, but not something we can backport without creating issues.