From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/14168 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: sva sva Newsgroups: gmane.linux.lib.musl.general Subject: Re: Hijacking malloc called within musl libc Date: Fri, 31 May 2019 00:13:27 -0400 Message-ID: References: <20190530222959.GU16415@port70.net> Reply-To: musl@lists.openwall.com Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000459729058a273d8b" Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="123286"; mail-complaints-to="usenet@blaine.gmane.org" To: musl@lists.openwall.com Original-X-From: musl-return-14184-gllmg-musl=m.gmane.org@lists.openwall.com Fri May 31 06:13:58 2019 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.89) (envelope-from ) id 1hWYvU-000Vq3-2h for gllmg-musl@m.gmane.org; Fri, 31 May 2019 06:13:56 +0200 Original-Received: (qmail 1236 invoked by uid 550); 31 May 2019 04:13:53 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 1188 invoked from network); 31 May 2019 04:13:52 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=I+MNRpu/xvYVx0U9T2hEiFC3l9oYRQSSV5V74bfXqNw=; b=WXCI52UBubbJ4aAuCrdHejvqVng8TN8kODAjw60sYDlOn/h2xTHmr3exw3W90UpBPp g+6IJryCJomjaghzH4OmhdaQ0wqY5SjXeJ6i3eJEX+A+igr9NrverruF/XcWST4L0ETI ojcILr0Glt2GKS3qCnFDcgTTXPvUbxv599cobhJUHGqRRVoaMUldVT+/bZSA1qvISs// mCqZPjFUZ4BAyVnk1MOW0I6AKsry3U8TiZMi3e4X9Izm8bMfHqeQVuh0E/pOPgCECk7q dsOPe+uX7r1KuJsAy3GE8magAcGYZiTLMRmoyjLjEn5lHwO/IlId/XJTQc9ngN8WXSZ6 XXPQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=I+MNRpu/xvYVx0U9T2hEiFC3l9oYRQSSV5V74bfXqNw=; b=o/Qvi3hxlsVKfsjdpAqLR7eXom29Dua6Hq31+Ed+t3mkWRKTE+oHtEsUYNrvxCqmRN T6J3yMcyDua+18/fRKkrOLaxdl3SgWTH5PQn5hpWPC2YvChRJ076od0bWIHfaR6+Rv/e xIbpsDtv93GT5ioe9DJVAecqiDiTxnGYHTT/kMVOEtAUIzA88+LIj+wU+k86aNsrWQyC LhZgdfCwPtjRRFVvOUTR0sRgbj/EOX2+W5hYez5rLW8kgPyxKVW2n6QLlGVKwxa4b2hZ X1rlxL/X15plx2e/Bxa9y26v6AQmhi60ncXg8h82w7h2VmlAzJrzKiAf206VmdM2J6tF N28A== X-Gm-Message-State: APjAAAXxbG2i5qrgWyNVgzuTdLIpk9MVaCoTiJ3lIFsPms1NjHOi0Cca B8UQvvwvARYFQ0iJcPB8szmHPGVCEFDS5SPc0tRSurdm X-Google-Smtp-Source: APXvYqyenmVt7se71y0Gg0upVCJAC42RHP3ejSmM0cvULCT3JIRcjrgnOfVRG1sPf2rpr2UnRJWCm7bUTOZ+AjAMH+0= X-Received: by 2002:a05:660c:f87:: with SMTP id x7mr6067075itl.163.1559276019880; Thu, 30 May 2019 21:13:39 -0700 (PDT) In-Reply-To: <20190530222959.GU16415@port70.net> Xref: news.gmane.org gmane.linux.lib.musl.general:14168 Archived-At: --000000000000459729058a273d8b Content-Type: text/plain; charset="UTF-8" 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 wrote: > * 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 > --000000000000459729058a273d8b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I am interposing all malloc/calloc/realloc/free/memal= ign but still the realloc in scandir gets called from musl's libc. Does= that make sense?

Vahid

On Thu, May 30, 2= 019 at 6:30 PM Szabolcs Nagy <nsz@port= 70.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 ca= lled

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 thos= e to be
> overloaded as well.
>
> More specifically this is the part of libc for scandir code at
> src/dirent/scandir.c:
> tmp =3D 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.<= br> > 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
--000000000000459729058a273d8b--