[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20190126135926.GZ21289@port70.net>
Date: Sat, 26 Jan 2019 14:59:26 +0100
From: Szabolcs Nagy <nsz@...t70.net>
To: musl@...ts.openwall.com
Cc: r yang <decatf@...il.com>
Subject: Re: Infinite loop in malloc
* Rich Felker <dalias@...c.org> [2019-01-25 20:30:14 -0500]:
> On Sat, Jan 26, 2019 at 12:11:37AM +0100, Szabolcs Nagy wrote:
> > * Szabolcs Nagy <nsz@...t70.net> [2019-01-25 23:28:32 +0100]:
> > > * r yang <decatf@...il.com> [2019-01-25 10:13:50 -0500]:
> > > > pmbootstrap is a development environment to build/install postmarketOS
> > > > (based on Alpine Linux) for Android devices. One of the things it does
> > > > is use qemu static to emulate an ARM based Alpine Linux chroot
> > > > environment.
> > > >
> > > > There is a bug while compiling certain packages in the qemu ARM chroot.
> > > > The qemu process can get stuck in an infinite loop when calling malloc.
> > > >
> > > > pmbootstrap uses Alpine Linux edge repositories. It's using the current
> > > > musl package version 1.1.20.
> > > >
> > > > Here is a gdb backtrace.
> > > > #0 malloc (n=<optimized out>, n@...ry=9) at src/malloc/malloc.c:320
> > > > #1 0x0000000060184ad3 in g_malloc (n_bytes=n_bytes@...ry=9) at gmem.c:99
> > > > #2 0x000000006018bcab in g_strdup (str=<optimized out>, str@...ry=0x60200abf "call_rcu") at gstrfuncs.c:363
> > > > #3 0x000000006016e31d in qemu_thread_create (thread=thread@...ry=0x7ffe89fb1a10, name=name@...ry=0x60200abf "call_rcu",
> > > > start_routine=start_routine@...ry=0x60174c00 <call_rcu_thread>, arg=arg@...ry=0x0, mode=mode@...ry=1) at /home/pmos/build/src/qemu-3.1.0/util/qemu-thread-posix.c:526
> > > > #4 0x0000000060174b99 in rcu_init_complete () at /home/pmos/build/src/qemu-3.1.0/util/rcu.c:327
> > > > #5 0x00000000601c4fac in __fork_handler (who=1) at src/thread/pthread_atfork.c:26
> > > > #6 0x00000000601be8db in fork () at src/process/fork.c:33
> >
> > it seems the issue is simply that qemu-arm-static is a multi-threaded
> > process and here it forks and calls malloc in the fork handler of
> > the child process.
> >
> > it's easy to imagine that if fork runs concurrently with a free
> > the malloc state remains corrupted in the child hence the malloc
> > fails there.
> >
> > i'm not sure if musl can detect or fix this up easily.
>
> In that case it's undefined behavior by qemu. After a multithreaded
> process forks, the child process is permanently in an async signal
> context. Calling malloc or any other AS-unsafe function is undefined.
>
> Without knowing what qemu is trying to do, it's not clear how fixable
> this might be.
reported at
https://bugs.launchpad.net/qemu/+bug/1813398
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.
