[cautious_int]

This is a common problem in C. Integer types are inherently type unsafe and are silently promoted with many different rules which are hard to remember and understand. As is seen in this case, even the ( borderline paranoid ) flag -Wconversion would not catch the bug.

I think this problem in C would be solved with a single flag: -Wwarn-if-using-integers-of-different-types-in-an-operation , forcing you to cast the integer if the types don't match in a arithmetic operation, or an assignment.

[Dylan16807]

I can understand the comparison passing, but why in the world does nothing warn about the truncation inside the new operator?

[cautious_int]

Because no truncation happens. In this case [] operator doesn't specify any type, only that the expression inside is an integer expression. While normally the type size_t is used for object and array sizes, [] takes any integer expression and the compiler won't complain.

[Dylan16807]

I'm talking about this line

  uint8_t *buffer = new (std::nothrow) uint8_t[size + chunk_size];

size + chunk_size is clearly unsafe to truncate to 32 bits, but it truncates anyway. When I say 'inside the new operator' I'm including the allocation function. Something truncates it. If it actually allocated 8GB, or failed to allocate 8GB, there would be no exploit.

[cautious_int]

I was talking about the same line.

Apparently new is a "special" operator, or there is a bug in the compiler. I also can't get a warning with g++.

The problem seems to be that, as I said, [] takes any integer expression, it is there where the value gets truncated when operator sizeof or new is applied on it since they either return or take a size_t value.