* Karl Chen: > "4 * n", unchecked, is vulnerable to integer overflow. On IA-32, > "new int[0x40000001]" becomes equivalent to "new int[1]". I've > verified this on gcc-2.95 through 4.1. For larger objects the > effects are exaggerated; smaller counts are needed to overflow.
This PR19351, by the way. The most widespread interpretation of the standard is that conforming implementations aren't allowed to raise an exception in this case: the arithmetic is defined to occur in terms of an unsigned type. See the 2005 discussion on comp.std.c++ on this topic. > This is similar to the calloc integer overflow vulnerability in > glibc, which was fixed back in 2002. Interestingly, RUS-CERT > 2002-08:02 did mention 'operator new', and so did Bugtraq 5398. > http://cert.uni-stuttgart.de/advisories/calloc.php > http://www.securityfocus.com/bid/5398/discuss Yeah, I've essentially given up on this one. The official response from the C++ folks is here: http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_closed.html#256 | Each implementation is required to document the maximum size of an | object (Annex B limits). It is not difficult for a program to check | array allocations to ensure that they are smaller than this | quantity. Implementations can provide a mechanism in which users | concerned with this problem can request extra checking before array | allocations, just as some implementations provide checking for array | index and pointer validity. However, it would not be appropriate to | require this overhead for every array allocation in every program.
