malloc（）与堆溢出说明

Question

I have the following code:

int main(int argc, char *argv[]) {

    int bufferSize = 8;
    //Setting the buffer size here, which can cause a heap overflow
    char *argsStr = malloc(bufferSize);
    char *anotherStr = malloc(bufferSize);

    //If argv[1] is greater than the buffer size, we will have an overflow
    strcpy(argsStr, argv[1]);

    printf("String 1: %s String 2: %s", argsStr, anotherStr);

}

I want to cause a heap overflow, so I import the param 'testtesttesttesttesttesttesttesttest'.

I would expect, since argsStr is only of size 8, it would be 'testtest' and the rest would overflow into anotherStr (for 8 bytes), but instead I see:

so argsStr is 'testtesttesttesttesttesttesttesttest' and anotherStr is 'testtesttesttesttest'

Why is this? Am I missing something with heap overflows or malloc() ?

Answer 1

printf() doesn't know or care how much memory you allocated for the buffers. When it's printing a string with %s format, it keeps printing until it reaches the terminating zero byte. So when it's printing argsStr , it prints the entire thing, even though it overflows the 8 bytes that were allocated. This is why buffer overflows are a problem -- C pointers don't include any information about how much memory is allocated, so you can easily access memory outside the allocated space if you don't check your lengths correctly.

The memory for anotherStr was apparently allocated 16 bytes after the memory for argsStr . So when you printed that, it started from the location of argsStr[16] , and printed the last 20 bytes of that string.

This is all undefined behavior, of course, so you can't depend on any specific result.

Answer 2

I would expect, since argsStr is only of size 8, it would be testtest and the rest would overflow into anotherStr

In order for the argsStr string to stop after 8 characters on printing, 9-th character must be '\\0' . Your string does not have it, hence printf does not know to stop after printing the first 8 characters on %s .

You got your heap overflow, because strcpy blew past the allocated size. It also blew through the "bookkeeping info" stored by malloc , and spills into the next allocation. Of course it does not have to go into the next allocated block, because it's undefined behavior; it just happened to do it on your particular system.

You can tell that there was a heap overflow by running your program through valgrind . Chances are, your program is going to crash when you add calls to free the memory that you allocated.

Answer 3

As you know, when you do a malloc, it gives you a pointer to a block of memory in the heap. The exact structure of the heap is implementation dependent. As others have observed, you may or may not get sequential memory and you may or may not get exactly the amount of memory you asked for. There are debug implementations malloc that give you the memory you asked for plus a big area at the end with markers to allow finding when you overwrite the end of your allocated block. Something else to keep in mind is the second malloc could be either before or after the memory for the first malloc. Like MM observed, you could do a %p to see where the blocks are located to get an idea if they can run into each other.

This is what is called undefined behavior. Exploring undefined behavior is great fun and allows you to get insights into the implementation but don't be surprised if it changes with a different version. You can almost be guaranteed that it will change substantially on different systems, even with the same (GCC) compiler.

If you are really interested, you could find the source for the GCC run time library malloc routine on the web and see what goes on inside. I just searched for "gcc runtime library malloc source" and found something that will take more than a few minutes examination to make sense out of. It is pretty awesome code. A lot of very smart people spent a long time working on it.