avr-libc-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[avr-libc-dev] [bug #25723] Realloc corrupts free list when growing into


From: anonymous
Subject: [avr-libc-dev] [bug #25723] Realloc corrupts free list when growing into the next free item
Date: Sat, 28 Feb 2009 02:06:09 +0000
User-agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_5_6; en-us) AppleWebKit/528.16 (KHTML, like Gecko) Version/4.0 Safari/528.16

URL:
  <http://savannah.nongnu.org/bugs/?25723>

                 Summary: Realloc corrupts free list when growing into the
next free item
                 Project: AVR C Runtime Library
            Submitted by: None
            Submitted on: Sat 28 Feb 2009 02:06:08 AM UTC
                Category: Library
                Severity: 3 - Normal
                Priority: 5 - Normal
              Item Group: libc code
                  Status: None
        Percent Complete: 0%
             Assigned to: None
             Open/Closed: Open
         Discussion Lock: Any
                 Release: 1.6.3
           Fixed Release: None

    _______________________________________________________

Details:

void testMalloc()
{
    size_t* array = (size_t*)malloc(4 * sizeof(size_t));
    free(array);
    array = NULL;
 
    array = (size_t*)realloc(array, sizeof(size_t));
    array = (size_t*)realloc(array, 2 * sizeof(size_t));
    array = (size_t*)realloc(array, 3 * sizeof(size_t));
    realloc(array, 4 * sizeof(size_t));
}
There is a bug in the free list manager in Realloc, specifically when growing
a buffer into the next free entry. I was convinced I had a bug in a fairly
large codebase, and whittled it down to this reproduction. I’m now playing
with a couple of fixes, but need to figure out how to get a ‘blessed’ fix
into lib-avr.

Stepping through the malloc into the free results in:

00000010 00000000 00000000 00000000
00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000
Over the first realloc:

00000008 00000000 00000000 00000004
00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000
Over the third:

0000000c 00000000 00000000 00000004
00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000
And finally:

00000010 00000000 00000000 00000004
00000000 FFFFFFFC 00000000 00000000
00000000 00000000 00000000 00000000
At this point the free block pointer (__flp) points to the second line, with
a size of 0xfffffffc. The next allocation fails.

I've tracked it down to some free list tracking code in realloc.c, here's a
patch for the fix, which I have verified.

Index: realloc.c
===================================================================
RCS file: /sources/avr-libc/avr-libc/libc/stdlib/realloc.c,v
retrieving revision 1.4
diff -r1.4 realloc.c
49c49
< 
---
>       
53c53
< 
---
>       
57c57
< 
---
>       
60c60
<               /* Pointer wrapped across top of RAM, fail. */
---
>       /* Pointer wrapped across top of RAM, fail. */
62,63c62,63
<       fp2 = (struct __freelist *)cp;
< 
---
>       fp2 = (struct __freelist *)(cp - sizeof(size_t));
>       
82c82
< 
---
>       
87c87
<       incr = len - fp1->sz - sizeof(size_t);
---
>       incr = len - fp1->sz;
89d88
<       fp2 = (struct __freelist *)cp;
91,92c90,91
<            fp3;
<            ofp3 = fp3, fp3 = fp3->nx) {
---
>               fp3;
>               ofp3 = fp3, fp3 = fp3->nx) {
95,96c94
<                       if (incr <= fp3->sz &&
<                           incr > fp3->sz - sizeof(struct __freelist)) {
---
>                       if (incr <= fp3->sz + sizeof(size_t)) {
107c105
<                       fp2 = (struct __freelist *)cp;
---
>                       fp2 = (struct __freelist *)(cp - sizeof(size_t));
144c142
< 
---
>       






    _______________________________________________________

Reply to this item at:

  <http://savannah.nongnu.org/bugs/?25723>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.nongnu.org/





reply via email to

[Prev in Thread] Current Thread [Next in Thread]