Re: Hijacking malloc called within musl libc

[sva sva <azharivs@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1794 bytes --]

I am interposing all malloc/calloc/realloc/free/memalign but still the
realloc in scandir gets called from musl's libc. Does that make sense?

Vahid

On Thu, May 30, 2019 at 6:30 PM Szabolcs Nagy <nsz@port70.net> wrote:

> * sva sva <azharivs@gmail.com> [2019-05-30 16:39:48 -0400]:
> > I am LD_PRELOADing an application my own malloc which eventually calls
> the
> > libc malloc. Everything is fine until the code hits malloc which is
> called
>
> musl has explicit checks not to allow libc internal malloc
> calls if user malloc is used (at least for memalign),
> because mixing user malloc and libc malloc is problematic.
>
> this means that currently the common malloc wrapping methods
> don't work on musl. (you can try to copy the musl malloc
> implementation into an external library and work with that
> instead of calling back to libc malloc, but it might need
> some changes)
>
> > from musl's own libc which doesn't get overloaded. I want those to be
> > overloaded as well.
> >
> > More specifically this is the part of libc for scandir code at
> > src/dirent/scandir.c:
> > tmp = realloc(names, len * sizeof *names);
>
> if you define malloc/calloc/realloc/memalign/free then
> all musl internal calls to those functions will go to
> your definitions (including the realloc in scandir).
>
> (if you only interpose a subset of the malloc functions
> that's broken and cannot work)
>
> >
> > I checked how this works for glibc, and apparently they use
> > __libc_malloc/etc. internally and have malloc as a weak alias for that
> > which is used every where including the rest of the standard library.
> > However in musl, there is no such thing as a weak alias defined for
> > malloc/etc.
> >
> > I am kind of stuck here so would appreciate some help.
> >
> > Thanks
> >
> > Vahid
>

[-- Attachment #2: Type: text/html, Size: 2374 bytes --]