Hijacking malloc called within musl libc

Hijacking malloc called within musl libc

[sva sva]

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

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
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);

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: 926 bytes --]

Re: Hijacking malloc called within musl libc

[Szabolcs Nagy]

* 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

Re: Hijacking malloc called within musl libc

[sva sva]

[-- 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 --]

Re: Hijacking malloc called within musl libc

[Szabolcs Nagy]

* sva sva <azharivs@gmail.com> [2019-05-31 00:13:27 -0400]:
> 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?

no.

it works for me as expected.

you need to write down what you did, what you expected and what you got instead.
(how did you verify that the musl internal realloc gets called?
it can be a bug in your interposer, in your static linker, in ...)

$ cat a.c
#include <dirent.h>
#include <string.h>
#include <stdio.h>
#include <malloc.h>

void *realloc(void *p, size_t size)
{
	printf("realloc %p %zu\n", p, size);
	void *q = malloc(size);
	if (p)
		memcpy(q, p, malloc_usable_size(p));
	return q;
}

static int cmp(const struct dirent **a, const struct dirent **b)
{
	return 0;
}

int main()
{
	struct dirent **de = 0;
	int r = scandir(".", &de, 0, cmp);
	for (int i=0; i<r; i++)
		printf("%d %s\n", i, de[i]->d_name);
}
$ gcc a.c
$ ./a.out
realloc 0 8
realloc 0xffff93274860 24
realloc 0xffff932748c0 56
0 .
1 a.c
2 ..
3 a.out


> 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
> >

Re: Hijacking malloc called within musl libc

[Rich Felker]

On Fri, May 31, 2019 at 01:43:17PM +0200, Szabolcs Nagy wrote:
> * sva sva <azharivs@gmail.com> [2019-05-31 00:13:27 -0400]:
> > 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?
> 
> no.
> 
> it works for me as expected.
> 
> you need to write down what you did, what you expected and what you got instead.
> (how did you verify that the musl internal realloc gets called?
> it can be a bug in your interposer, in your static linker, in ...)

It's almost certainly a matter of using a pre-1.1.20 version of musl,
or having an old config.mak from pre-1.1.20 musl (with
-Bsymbolic-functions) rather than re-running configure with the
current version.

Rich

Re: Hijacking malloc called within musl libc

[sva sva]

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

I am in fact using version 1.1.19 and don't have the option to upgrade to
1.1.20. My config.mak file also contains the option -Bsymbolic-functions in
the LDFLAGS_AUTO variable.

On Fri, May 31, 2019 at 9:34 AM Rich Felker <dalias@libc.org> wrote:

> On Fri, May 31, 2019 at 01:43:17PM +0200, Szabolcs Nagy wrote:
> > * sva sva <azharivs@gmail.com> [2019-05-31 00:13:27 -0400]:
> > > 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?
> >
> > no.
> >
> > it works for me as expected.
> >
> > you need to write down what you did, what you expected and what you got
> instead.
> > (how did you verify that the musl internal realloc gets called?
> > it can be a bug in your interposer, in your static linker, in ...)
>
> It's almost certainly a matter of using a pre-1.1.20 version of musl,
> or having an old config.mak from pre-1.1.20 musl (with
> -Bsymbolic-functions) rather than re-running configure with the
> current version.
>
> Rich
>

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

Re: Hijacking malloc called within musl libc

[Rich Felker]

On Mon, Jun 03, 2019 at 02:46:01PM -0400, sva sva wrote:
> I am in fact using version 1.1.19 and don't have the option to upgrade to
> 1.1.20. My config.mak file also contains the option -Bsymbolic-functions in
> the LDFLAGS_AUTO variable.

1.1.20 was the first version that supported malloc interposition, and
some related bugs were fixed in the next 1 or 2 versions. Just
removing -Bsymbolic-functions is not sufficient to make it safe.

Rich


> On Fri, May 31, 2019 at 9:34 AM Rich Felker <dalias@libc.org> wrote:
> 
> > On Fri, May 31, 2019 at 01:43:17PM +0200, Szabolcs Nagy wrote:
> > > * sva sva <azharivs@gmail.com> [2019-05-31 00:13:27 -0400]:
> > > > 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?
> > >
> > > no.
> > >
> > > it works for me as expected.
> > >
> > > you need to write down what you did, what you expected and what you got
> > instead.
> > > (how did you verify that the musl internal realloc gets called?
> > > it can be a bug in your interposer, in your static linker, in ...)
> >
> > It's almost certainly a matter of using a pre-1.1.20 version of musl,
> > or having an old config.mak from pre-1.1.20 musl (with
> > -Bsymbolic-functions) rather than re-running configure with the
> > current version.