Bug 1349

Summary: malloc_usable_size() incorrect when MALLOC_CHECK_>0
Product: glibc Reporter: Jim Kearney <jkearney>
Component: mallocAssignee: Siddhesh Poyarekar <siddhesh>
Status: RESOLVED FIXED    
Severity: normal CC: aj, clausen, glibc-bugs, ppluzhnikov, siddhesh
Priority: P2 Flags: fweimer: security-
Version: 2.3.5   
Target Milestone: ---   
Host: Target:
Build: Last reconfirmed: 2012-05-06 00:00:00

Description Jim Kearney 2005-09-17 18:09:08 UTC
When MALLOC_CHECK_>0, an extra byte is added to each allocation for checking. 
malloc_usable_size() doesn't take this extra byte off the return value in this
case.  Try the following with MALLOC_CHECK_=2:

    void* p = malloc(7);
    size_t usable = malloc_usable_size(p);
    memset(p, 0, usable);
    p = realloc(p, 7);
Comment 1 Ulrich Drepper 2005-09-28 22:45:54 UTC
You are misusing malloc_usable_size().  The function gives you information on
how much memory a really call can provide you in place.  It does not
automagically extends the memory block.  The realloc call is needed.

Admittedly, the information returned by malloc_usable_size() doesn't take the
magic byte into account and therefore a really call, which would normally be
extended in place, can require a repositioning.  But this is no big issue and
not worth changing.

In summary: your test code is wrong and deserves to crash.
Comment 2 Jim Kearney 2005-09-29 01:22:38 UTC
Subject: RE:  malloc_usable_size() incorrect when MALLOC_CHECK_>0

Ulrich, I'm not sure that we're communicating here.  The comment for malloc_usable_size() says:

  Returns the number of bytes you can actually use in
  an allocated chunk, which may be more than you requested (although
  often not) due to alignment and minimum size constraints.
  You can use this many bytes without worrying about
  overwriting other allocated objects.

The code sample given conforms to this contract, and works fine when MALLOC_CHECK_=0.  When MALLOC_CHECK_ is not 0, the magic byte is overwritten because it is not accounted for.  Therefore, *any* operation that checks the magic bytes after the memset() will report an error and/or abort.  Change realloc() to free() and the same thing will happen.  It has nothing to do with "extension" or "repositioning".

Granted, it's a usage which is not very nice, but I don't think it's "misusing malloc_usable_size()".

-----Original Message-----
From: drepper at redhat dot com
[mailto:sourceware-bugzilla@sourceware.org]
Sent: Wednesday, September 28, 2005 6:46 PM
To: Jim Kearney
Subject: [Bug libc/1349] malloc_usable_size() incorrect when
MALLOC_CHECK_>0



------- Additional Comments From drepper at redhat dot com  2005-09-28 22:45 -------
You are misusing malloc_usable_size().  The function gives you information on
how much memory a really call can provide you in place.  It does not
automagically extends the memory block.  The realloc call is needed.

Admittedly, the information returned by malloc_usable_size() doesn't take the
magic byte into account and therefore a really call, which would normally be
extended in place, can require a repositioning.  But this is no big issue and
not worth changing.

In summary: your test code is wrong and deserves to crash.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |INVALID


http://sourceware.org/bugzilla/show_bug.cgi?id=1349

------- You are receiving this mail because: -------
You reported the bug, or are watching the reporter.

This email message and any attachments are confidential to Endeca. If you are not the intended recipient, please notify Endeca immediately -- by replying to this message or by sending an email to: legal@endeca.com -- and destroy all copies of this message and any attachments. Thank you.


Comment 3 Andrew Clausen 2011-04-16 15:34:58 UTC
I agree that this is a real bug.  I want to memset(ptr, 0, malloc_usable_size(ptr)) my memory on free(3), so that my computer forgets all of my private information.  This should work with mcheck() and friends.
Comment 4 Andreas Jaeger 2012-02-06 14:06:43 UTC
Looking at the documentation of malloc_usable_size, I agree this is a bug in glibc.

IMO for the snippet in the report, usable should be 7 with MALLOC_CHECK_>0.
Comment 5 Siddhesh Poyarekar 2012-09-05 16:22:31 UTC
Fixed in master: 6ef9cc37f0ea151a54e5c8a19950a6d5b6ff8a96
Comment 6 Jackie Rosen 2014-02-16 17:50:41 UTC Comment hidden (spam)