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=-3.3 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 12663 invoked from network); 24 May 2021 20:33:46 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 24 May 2021 20:33:46 -0000 Received: (qmail 22372 invoked by uid 550); 24 May 2021 20:33:43 -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 22354 invoked from network); 24 May 2021 20:33:43 -0000 Date: Mon, 24 May 2021 16:33:30 -0400 From: Rich Felker To: Alexey Izbyshev Cc: musl@lists.openwall.com Message-ID: <20210524203329.GB2546@brightrain.aerifal.cx> References: <985e15962c164eb3076752d6ee4c05fe@ispras.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <985e15962c164eb3076752d6ee4c05fe@ispras.ru> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] Potentially infinite loop in posix_spawn'ed child On Mon, May 24, 2021 at 01:09:21PM +0300, Alexey Izbyshev wrote: > Hi, > > I've noticed the following loop at https://git.musl-libc.org/cgit/musl/tree/src/process/posix_spawn.c#n159: > > exec(args->path, args->argv, args->envp); > ret = -errno; > > fail: > /* Since sizeof errno < PIPE_BUF, the write is atomic. */ > ret = -ret; > if (ret) while (__syscall(SYS_write, p, &ret, sizeof ret) < 0); > _exit(127); > > Is there any reason that write is done in a loop? If SIGPIPE is > blocked or ignored and the parent dies before this point, the child > will spin in it forever. I suppose the special case of EPIPE should be considered here as no need to inform the parent. Are there any other errors that should be treated specially? > A test case is attached. It overrides execve() to abuse it as a > callback, avoiding reliance on timings. As noted that's undefined but it's completely reasonable as a way to do the testing. Using seccomp to make the parent die might be slightly less hackish but it doesn't matter. Thanks for the report. Rich