On 9/15/20 1:47 PM, Martin Sebor wrote: > Overflowing the size of a dynamic allocation (e.g., malloc or VLA) > can lead to a subsequent buffer overflow corrupting the heap or > stack. The attached patch diagnoses a subset of these cases where > the overflow/wraparound is still detectable. > > Besides regtesting GCC on x86_64-linux I also verified the warning > doesn't introduce any false positives into Glibc or Binutils/GDB > builds on the same target. > > Martin > > gcc-96838.diff > > PR middle-end/96838 - missing warning on integer overflow in calls to > allocation functions > > gcc/ChangeLog: > > PR middle-end/96838 > * calls.c (eval_size_vflow): New function. > (get_size_range): Call it. Add argument. > (maybe_warn_alloc_args_overflow): Diagnose overflow/wraparound. > * calls.h (get_size_range): Add argument. > > gcc/testsuite/ChangeLog: > > PR middle-end/96838 > * gcc.dg/Walloc-size-larger-than-19.c: New test. > * gcc.dg/Walloc-size-larger-than-20.c: New test.
If an attacker can control an integer overflow that feeds an allocation, then they can do all kinds of bad things. In fact, when my son was asking me attack vectors, this is one I said I'd look at if I were a bad guy. I'm a bit surprised you can't just query the range of the argument and get the overflow status out of that range, but I don't see that in the APIs. How painful would it be to make that part of the API? The conceptual model would be to just ask for the range of the argument to malloc which would include the range and a status bit indicating the computation might have overflowed. jeff
pEpkey.asc
Description: application/pgp-keys
