[Bug malloc/17730] New: thread-local storage is sometimes improperly free()'d after being __libc_memalign()'d

[Bug malloc/17730] New: thread-local storage is sometimes improperly free()'d after being __libc_memalign()'d

[bradley at mit dot edu]

https://sourceware.org/bugzilla/show_bug.cgi?id=17730

            Bug ID: 17730
           Summary: thread-local storage is sometimes improperly free()'d
                    after being __libc_memalign()'d
           Product: glibc
           Version: 2.18
            Status: NEW
          Severity: normal
          Priority: P2
         Component: malloc
          Assignee: unassigned at sourceware dot org
          Reporter: bradley at mit dot edu

Created attachment 8020
  --> https://sourceware.org/bugzilla/attachment.cgi?id=8020&action=edit
test case

Sometimes libc obtains a block of memory using __libc_memalign(), and then
later deallocates the block using free().  

Since malloc/free may be redefined to be unrelated to the libc internal
malloc/free code, this is incorrect.  (malloc/free might be redefined in the
user code directly, or it might be installed using LD_PRELOAD or it might be
that another implementation of malloc is linked dynamically or statically into
the application).

Here are the conditions under which I can reproduce this problem:
 * The main user code defines its own malloc/free
 * The main user code dynamically loads a library using dlopen()/dlsym().
 * The library contains thread-local storage.
 * A thread runs, and then proceeds to touch the thread-local storage,
eventually invoking tls_get_addr_tail() (in /elf/dl-tls.c) and then
allocate_and_init() and then __libc_memalign().
 * Eventually, this storage is deallocated using free() instead __libc_free().

I ran this on Fedora 20, but it looks like the problem is still there on the
head of the git master of glibc.

Attached is a test case.  This test case implements its own very simple
malloc/free library and free complains if it is given a pointer which didn't
come from the library. It runs as follows. Observe the abort at the end.

[bradley@30-87-232 test]$ tar xfz libc-bug.tar.gz 
[bradley@30-87-232 test]$ cd libc-bug/
[bradley@30-87-232 libc-bug]$ make check
gcc -g -W -Wall -Werror -pthread -fPIC --shared libtls.c -o libtls.so
cc -g -W -Wall -Werror -pthread -fPIC    tls.c  -ldl -o tls
./tls
malloc(32)=0x6020c0
malloc(46)=0x6020e0
malloc(1214)=0x60210e
malloc(46)=0x6025cc
malloc(56)=0x6025fa
malloc(96)=0x602632
malloc(288)=0x602692
malloc(288)=0x6027b2
malloc(288)=0x6028d2
malloc(288)=0x6029f2
1048576
1048576
1048576
malloc(288)=0x602b12
1048576
1048576
free passed 0xea1010 not in range
make: *** [check] Aborted (core dumped)
[bradley@30-87-232 libc-bug]$

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug malloc/17730] thread-local storage is sometimes improperly free()'d after being __libc_memalign()'d

[fweimer at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=17730

Florian Weimer <fweimer at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |fweimer at redhat dot com
              Flags|                            |security-

--- Comment #1 from Florian Weimer <fweimer at redhat dot com> ---
I think the only way to fix this is not to call memalign at all, under any
name.

We cannot use the memalign name because it is not in the implementation
namespace for all standards.  At the same time, we have to call this function
(and not the glibc implementation) to get the definition from the external
malloc implementation.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug malloc/17730] thread-local storage is sometimes improperly free()'d after being __libc_memalign()'d

[bradley at mit dot edu]

https://sourceware.org/bugzilla/show_bug.cgi?id=17730

--- Comment #2 from Bradley C. Kuszmaul <bradley at mit dot edu> ---
Another possible fix is to call __libc_free() to free the storage instead of
calling free().

-- 
You are receiving this mail because:
You are on the CC list for the bug.