Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 24 May 2021 19:50:57 +0300
From: Alexey Izbyshev <>
To: Szabolcs Nagy <>
Subject: Re: Potentially infinite loop in posix_spawn'ed child

On 2021-05-24 18:40, Szabolcs Nagy wrote:
> * Alexey Izbyshev <> [2021-05-24 13:09:21 +0300]:
>> As an aside, perhaps it would make sense to call execve() in 
>> posix_spawn()
>> implementation via a hidden symbol? This would both make it consistent 
>> with
>> posix_spawnp() and avoid any trouble with user code executing in a 
>> vfork'ed
>> child if execve() is overridden via e.g. LD_PRELOAD.
> libc symbols cannot be interposed by user code, they are
> all resolved within the libc, there should be no dynamic
> symbolic relocation in except for global data and
> malloc symbols (those are explicitly exported).
Thanks, I wasn't aware of musl's usage of --dynamic-list and thought 
that weak aliases to hidden symbols (like "weak_alias(__pthread_exit, 
pthread_exit)") are there to prevent interposition.

>> int execve(const char *path, char *const argv[], char *const envp[]) {
> this is only called with static linking, but that is not
> supportable usage: libc may provide execve and e.g. signal
> in the same object file and then there is a conflict
> because signal has to be linked. so this is just a user
> error.
I never intended this test case to be "supportable usage". This is just 
a hack to make the problem with infinite loop reliably reproducible.


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.