malloc question - what happens when chunk gets free?

Hello,

I try to understand heap overflows (under Linux), but can not understand
one
thing with freeing memory allocated with malloc(). Here it comes:

I have a program called 1.c:
main() {
char *a, *b, *c, *d, *e;
a = malloc(8);
b = malloc(8);
c = malloc(8);
strcpy(a, "AAA");
strcpy(b, "BBB");
strcpy(c, "CCC");
free(c);
free(b);
free(a);
}

Well, quite simple. Now I compile it:
[piotr::18:46:23]$ gcc 1.c -o 1 -ggdb

And run it under degugger:
[piotr::18:49:31]$ gdb 1
GNU gdb 6.0-debian
(...)
(gdb) l
(...)
7 strcpy(b, "BBB");
8 strcpy(c, "CCC");
9 free(c);
10 free(b);
(gdb) b 9
Breakpoint 1 at 0x804843a: file 1.c, line 9.
(gdb) r
Starting program:
/home/piotr/kieszen/in/warsztaty_linux/heap_overflow/robo/1/1
Breakpoint 1, main () at 1.c:9
9 free(c);
Ok, memory should be allocated and filled... Let's examine it:
(gdb) x/12 a-8
0x80496d8: 0x00000000 0x00000011 0x00414141 0x00000000
0x80496e8: 0x00000000 0x00000011 0x00424242 0x00000000
0x80496f8: 0x00000000 0x00000011 0x00434343 0x00000000
Seems that 0x11 is an information about chunk of memory... Bit "1" is
set, because previous chunk is in use. Let's see what happen when it's
freed.

I skip three lines in debugger...
(gdb) n
10 free(b);
(gdb) n
11 free(a);
(gdb) n
12 }

Now let's see at the same location in memory after it's freed.
(gdb) x/12 a-8
0x80496d8: 0x00000000 0x00000011 0x080496e8 0x00000000
0x80496e8: 0x00000000 0x00000011 0x080496f8 0x00000000
0x80496f8: 0x00000000 0x00000011 0x00000000 0x00000000
Ey, what's up?! Bit "1" is still set, even though chunks have been
freed?!

Do you know how is it? I even read sources of malloc.c and tried to look
at malloc.c under debugger, but it seems that line that should set that bit
to "0" is just skipped... Maybe some of you have more experience with
it?



--
zerro - root@[127.0.0.1]
Galeria tekstów - czytaj i komentuj cudze, poka¿ innym swoje.
http://www.rozrywka.jawsieci.pl/galeria_tekstow/

zerro@software.com.pl wrote in message news:<slrnc8s7fr.40e.zerro@piotr.software.com.pl>. ..
> Hello,
>
> I try to understand heap overflows (under Linux), but can not understand
> one
> thing with freeing memory allocated with malloc(). Here it comes:
>
> I have a program called 1.c:
> main() {
> char *a, *b, *c, *d, *e;
> a = malloc(8);
> b = malloc(8);
> c = malloc(8);
> strcpy(a, "AAA");
> strcpy(b, "BBB");
> strcpy(c, "CCC");
> free(c);
> free(b);
> free(a);
> }
>
> Well, quite simple. Now I compile it:
> [piotr::18:46:23]$ gcc 1.c -o 1 -ggdb
>
> And run it under degugger:
> [piotr::18:49:31]$ gdb 1
> GNU gdb 6.0-debian
> (...)
> (gdb) l
> (...)
> 7 strcpy(b, "BBB");
> 8 strcpy(c, "CCC");
> 9 free(c);
> 10 free(b);
> (gdb) b 9
> Breakpoint 1 at 0x804843a: file 1.c, line 9.
> (gdb) r
> Starting program:
> /home/piotr/kieszen/in/warsztaty_linux/heap_overflow/robo/1/1
> Breakpoint 1, main () at 1.c:9
> 9 free(c);
> Ok, memory should be allocated and filled... Let's examine it:
> (gdb) x/12 a-8
> 0x80496d8: 0x00000000 0x00000011 0x00414141 0x00000000
> 0x80496e8: 0x00000000 0x00000011 0x00424242 0x00000000
> 0x80496f8: 0x00000000 0x00000011 0x00434343 0x00000000
> Seems that 0x11 is an information about chunk of memory... Bit "1" is
> set, because previous chunk is in use. Let's see what happen when it's
> freed.
>
> I skip three lines in debugger...
> (gdb) n
> 10 free(b);
> (gdb) n
> 11 free(a);
> (gdb) n
> 12 }
>
> Now let's see at the same location in memory after it's freed.
> (gdb) x/12 a-8
> 0x80496d8: 0x00000000 0x00000011 0x080496e8 0x00000000
> 0x80496e8: 0x00000000 0x00000011 0x080496f8 0x00000000
> 0x80496f8: 0x00000000 0x00000011 0x00000000 0x00000000
> Ey, what's up?! Bit "1" is still set, even though chunks have been
> freed?!
>
> Do you know how is it? I even read sources of malloc.c and tried to look
> at malloc.c under debugger, but it seems that line that should set that bit
> to "0" is just skipped... Maybe some of you have more experience with
> it?


If you want to understand how it works then look at the code in glibc,
it is open for all to read.

AFAK malloc usually manages a list. When you do a free the freed bloc is
added to the free blocks lists. Allocated memory is not affected.

Then there are many algorithms, if you are interested in the most used
on linux you should have a look at glibc; but many project make their
own allocation library ( or use a special version ) which I think calls
directly sbrk

Rob Thorpe wrote:
> zerro@software.com.pl wrote in message news:<slrnc8s7fr.40e.zerro@piotr.software.com.pl>. ..
>
>>Hello,
>>
>>I try to understand heap overflows (under Linux), but can not understand
>>one
>>thing with freeing memory allocated with malloc(). Here it comes:
>>
>>I have a program called 1.c:
>>main() {
>> char *a, *b, *c, *d, *e;
>> a = malloc(8);
>> b = malloc(8);
>> c = malloc(8);
>> strcpy(a, "AAA");
>> strcpy(b, "BBB");
>> strcpy(c, "CCC");
>> free(c);
>> free(b);
>> free(a);
>>}
>>
>>Well, quite simple. Now I compile it:
>>[piotr::18:46:23]$ gcc 1.c -o 1 -ggdb
>>
>>And run it under degugger:
>>[piotr::18:49:31]$ gdb 1
>>GNU gdb 6.0-debian
>>(...)
>>(gdb) l
>>(...)
>>7 strcpy(b, "BBB");
>>8 strcpy(c, "CCC");
>>9 free(c);
>>10 free(b);
>>(gdb) b 9
>>Breakpoint 1 at 0x804843a: file 1.c, line 9.
>>(gdb) r
>>Starting program:
>>/home/piotr/kieszen/in/warsztaty_linux/heap_overflow/robo/1/1
>>Breakpoint 1, main () at 1.c:9
>>9 free(c);
>>Ok, memory should be allocated and filled... Let's examine it:
>>(gdb) x/12 a-8
>>0x80496d8: 0x00000000 0x00000011 0x00414141 0x00000000
>>0x80496e8: 0x00000000 0x00000011 0x00424242 0x00000000
>>0x80496f8: 0x00000000 0x00000011 0x00434343 0x00000000
>>Seems that 0x11 is an information about chunk of memory... Bit "1" is
>>set, because previous chunk is in use. Let's see what happen when it's
>>freed.
>>
>>I skip three lines in debugger...
>>(gdb) n
>>10 free(b);
>>(gdb) n
>>11 free(a);
>>(gdb) n
>>12 }
>>
>>Now let's see at the same location in memory after it's freed.
>>(gdb) x/12 a-8
>>0x80496d8: 0x00000000 0x00000011 0x080496e8 0x00000000
>>0x80496e8: 0x00000000 0x00000011 0x080496f8 0x00000000
>>0x80496f8: 0x00000000 0x00000011 0x00000000 0x00000000
>>Ey, what's up?! Bit "1" is still set, even though chunks have been
>>freed?!
>>
>>Do you know how is it? I even read sources of malloc.c and tried to look
>>at malloc.c under debugger, but it seems that line that should set that bit
>>to "0" is just skipped... Maybe some of you have more experience with
>>it?
>
>
>
> If you want to understand how it works then look at the code in glibc,
> it is open for all to read.