From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/14169 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Szabolcs Nagy Newsgroups: gmane.linux.lib.musl.general Subject: Re: Hijacking malloc called within musl libc Date: Fri, 31 May 2019 13:43:17 +0200 Message-ID: <20190531114317.GV16415@port70.net> References: <20190530222959.GU16415@port70.net> Reply-To: musl@lists.openwall.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="57880"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mutt/1.10.1 (2018-07-13) To: musl@lists.openwall.com Original-X-From: musl-return-14185-gllmg-musl=m.gmane.org@lists.openwall.com Fri May 31 13:43:32 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 1hWfwa-000EyK-RR for gllmg-musl@m.gmane.org; Fri, 31 May 2019 13:43:32 +0200 Original-Received: (qmail 28524 invoked by uid 550); 31 May 2019 11:43:30 -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 28503 invoked from network); 31 May 2019 11:43:29 -0000 Mail-Followup-To: musl@lists.openwall.com Content-Disposition: inline In-Reply-To: Xref: news.gmane.org gmane.linux.lib.musl.general:14169 Archived-At: * sva sva [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 #include #include #include 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; id_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 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 > >