tree 7f9010dbc4e8aac1e5bd8d716b08f3bdf158c0a4
parent 60eb9e173e8ca506f5cbfae9677f10dcf8c34297
author Nick Kralevich <nnk@google.com> 1428870026 -0700
committer Jouni Malinen <j@w1.fi> 1428922900 +0300

Updates for stricter automatic memcpy bounds checking

Both Android's libc and glibc support _FORTIFY_SOURCE, a compiler
and libc feature which inserts automatic bounds checking into
common C functions such as memcpy() and strcpy(). If a buffer
overflow occurs when calling a hardened libc function, the
automatic bounds checking will safely shutdown the program and
prevent memory corruption.

Android is experimenting with _FORTIFY_SOURCE=3, a new fortify
level which enhances memcpy() to prevent overflowing an element
of a struct. Under the enhancements, code such as

  struct foo {
    char empty[0];
    char one[1];
    char a[10];
    char b[10];
  };

  int main() {
    foo myfoo;
    int n = atoi("11");
    memcpy(myfoo.a, "01234567890123456789", n);
    return 0;
  }

will cleanly crash when the memcpy() call is made.

Fixup hostap code to support the new level. Specifically:

* Fixup sha1_transform so it works with the enhanced bounds checking.
The old memcpy() code was attempting to write to context.h0, but that
structure element is too small and the write was extending (by design)
into h1, h2, h3, and h4. Use explicit assignments instead of
overflowing the struct element.

* Modify most of the structures in ieee802_11_defs.h to use ISO C99
flexible array members (https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html)
instead of a zero length array. Zero length arrays have zero length,
and any attempt to call memcpy() on such elements will always overflow.
Flexible array members have no such limitation. The only element not
adjusted is probe_req, since doing so will generate a compile time error,
and it's not obvious to me how to fix it.

Signed-off-by: Nick Kralevich <nnk@google.com>