On Jul 14, 2015, at 11:01 AM, Joerg Mayer <jmayer@xxxxxxxxx> wrote:
> ... but have no idea how to find or fix:
Line 158 of the current epan/address.h is the
memcpy(to_data, from->data, from->len);
in copy_address().
The fact that it didn't *crash* is probably because from->len is zero, so it didn't actually try dereferencing either of the null pointers, and so that to_data, which is allocated based on from->len, is null.
I guess what it should do is
if (from->len != 0)
memcpy(to_data, from->data, from->len);
as ANSI C makes no guarantees that memcpy(NULL, NULL, 0) is harmless. (In practice, it's probably harmless in all implementations, but we shouldn't assume that.)
I just now checked that in as change I0b3dc1541b52670d8fef459754c9494cfcc59e5d.
Line 1558 of epan/crypt/airpdcap.c is
if (ctx->sa[ctx->first_free_index].used) {
in AirPDcapStoreSa(). It was assuming that ctx->first_free_index would be within the bounds of the array, which isn't guaranteed (what if there *are* no free indices?); I've added a bounds check in 4f1b8d74338ca2a6ded8498e9d87cbc3294454c0.
