in realloc(), memcpy() call would copy past end of allocation

or: Fix mem_size() to remove struct alloc_hdr from returned value

This bug was caught by switching test/run-malloc.c over to using
malloc/free (system malloc/free) to allocate the heap that we use
for testing our malloc and free.

Basically, when we did that, run-malloc.c test would get this
valgrind warning:
==3869== Invalid read of size 8
==3869==    at 0x4C2A706: memcpy (mc_replace_strmem.c:838)
==3869==    by 0x40323F: __realloc (malloc.c:69)
==3869==    by 0x405815: main (run-malloc.c:142)

Which was because in realloc(), when we have to relocate the allocated
bit of memory, we memcpy the contents of the old location into the new
one. The current mem_size() implementation *included* struct alloc_hdr
which mean that we were copying allocated size + sizeof(struct alloc_hdr)
from the returned pointer. This meant we read sizeof(struct alloc_hdr) past
the end of the allocation... which will pretty much always be harmless,
just get random junk in the realloc()ed space.

i.e. we would memcpy() 64+16 (80) bytes from the malloc(64) space to
the realloc(128) space, which is, obviously, 16 bytes more than we should.

IF we had some memory after a region that would make us explode if we read,
then we'd explode around the realloc() call... which would not be so good.
After a bit of a code audit I'm pretty sure this isn't going to actually
hurt us anywhere... or, at least, I hope not...

The fix is simple: fix mem_size() to subtract sizeof(struct alloc_hdr)
from the returned value. This should be okay with the other test case
that checks mem_size() result and there are no other mem_size() callers.

Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
Acked-by: Rusty Russell <rusty@au1.ibm.com>

0 files changed, 0 insertions, 0 deletions