Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 31 May 2019 00:29:59 +0200
From: Szabolcs Nagy <>
Subject: Re: Hijacking malloc called within musl libc

* sva sva <> [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

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.