Re: [lwip-users] mem_malloc bug

[Tom Hennen]

Well, from what I can tell this bug has existed for the entire history
of mem.c in CVS.

The bug seems to be a result of line 256, where the size of the 'mem'
struct is counted twice.  Instead of:

mem->next - (ptr + SIZEOF_STRUCT_MEM) >= size + SIZEOF_STRUCT_MEM)

It should read:

mem->next - ptr >= size + SIZEOF_STRUCT_MEM)

That isn't the only fix required however.  The code that updates mem2
assumes that mem2 is in some region of memory that isn't currently
allocated.  However, with the fix above (and the test case I provided
earlier) mem2 will point to a valid, already existing 'mem' struct and
so it shouldn't be updated.

To solve this problem after figuring out the value of ptr2 there
should be a check to see if mem->next points to ptr2, if it does then
mem2 is a valid struct and should be updated.  If it doesn't point to
ptr2 then it should be safe to create a new 'mem' struct at that
location.  Note that this solution ignores the problem of what would
happen if ptr2 actually pointed half-way into the existing 'mem'
struct.

On 10/4/06, Christiaan Simons <address@hidden> wrote:
> Hi Tom,
>
> > I've run across what I believe to be a bug in mem_malloc.
>
> Yikes. I'm currently working on some SNMP agent
> stuff that heavily uses mem_malloc()...
>
> > I have an idea why this is failing (and a possible method to fix it),
> > but I wanted to make sure this wasn't already known and expected.
>
> I wasn't aware of this. mem_malloc() did seem to work ok for me,
> but I may have missed this odd corner.
>
> Can you please share your thoughts with us?
>
> Christiaan Simons
>
> Hardware Designer
> Axon Digital Design
>
> http://www.axon.tv
>
>
>
> _______________________________________________
> lwip-users mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/lwip-users