From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.6 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,URIBL_BLACK autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 19680 invoked from network); 24 May 2021 16:51:10 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 24 May 2021 16:51:10 -0000 Received: (qmail 17453 invoked by uid 550); 24 May 2021 16:51:08 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 17432 invoked from network); 24 May 2021 16:51:08 -0000 MIME-Version: 1.0 Date: Mon, 24 May 2021 19:50:57 +0300 From: Alexey Izbyshev To: Szabolcs Nagy Cc: musl@lists.openwall.com In-Reply-To: <20210524154014.GA790988@port70.net> References: <985e15962c164eb3076752d6ee4c05fe@ispras.ru> <20210524154014.GA790988@port70.net> User-Agent: Roundcube Webmail/1.4.4 Message-ID: <02a4eba412e82db36c06952bc8b81825@ispras.ru> X-Sender: izbyshev@ispras.ru Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [musl] 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 libc.so 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. Alexey