[Bug middle-end/77608] missing protection on trivially detectable runtime buffer overflow

["kees at outflux dot net" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77608

Kees Cook <kees at outflux dot net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |kees at outflux dot net

--- Comment #5 from Kees Cook <kees at outflux dot net> ---
I think this behavior may, unfortunately, be "as expected", due to how the
memcpy overflow checks are working (they're checking surrounding object, yes,
like bos(0) would)? The constant-expression bos() calculations do appear to
understand the base pointer object, but when faced with "i", it can't know for
sure -- it might have room (if "i" is < 3), or not. So it must return -1 as it
lacks any other context (like memcpy's "size" argument).

There may, however, be a missing opportunity for tightening the memcpy checker?

For example:


...
volatile unsigned i;

struct weird {
    char a[4];
    char b[8];
};

int main (void)
{
  {
    struct weird instance;
    char d [3];

    P (d + i);
    memcpy (d + i, "abcdef", 5); // always overflows d (the entire object)

    i = 7;
    P (instance.a + i); // can't see into "i"
    P (instance.a + 7); // room left in instance (5), but not "a" (0)

    memcpy (instance.a + i, "abcdef", 5); // misses a, doesn't overflow
instance. should this warn?

    __builtin_printf ("%.0s", d);
  }
}


-1 -1  0  0
-1 -1  0  0
 5  0  5  5