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 16575 invoked from network); 25 May 2021 14:32:26 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 25 May 2021 14:32:26 -0000 Received: (qmail 1038 invoked by uid 550); 25 May 2021 14:32:23 -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 32762 invoked from network); 25 May 2021 14:32:23 -0000 Date: Tue, 25 May 2021 10:32:10 -0400 From: Rich Felker To: Alexey Izbyshev Cc: musl@lists.openwall.com Message-ID: <20210525143210.GH2546@brightrain.aerifal.cx> References: <985e15962c164eb3076752d6ee4c05fe@ispras.ru> <20210524203329.GB2546@brightrain.aerifal.cx> <47bc2113ebf931665b6b88795159de2e@ispras.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <47bc2113ebf931665b6b88795159de2e@ispras.ru> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] Potentially infinite loop in posix_spawn'ed child On Tue, May 25, 2021 at 09:30:18AM +0300, Alexey Izbyshev wrote: > On 2021-05-24 23:33, Rich Felker wrote: > >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? > > > I'm not aware of any other errors that would need treatment. Is this > loop intended to be a detection/debugging aid in case of an > unexpected error? It's not a debugging aid so much as a guarantee against forward progress doing the wrong thing (wrongly reporting success to the parent when the execve failed). I don't think there are any errors that should be able to happen here aside from EPIPE though, short of munging with syscall semantics using seccomp or something which is outside the scope of what could be expected to work correctly. Rich