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 8344 invoked from network); 24 May 2021 10:09:37 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 24 May 2021 10:09:37 -0000 Received: (qmail 14019 invoked by uid 550); 24 May 2021 10:09:33 -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 13980 invoked from network); 24 May 2021 10:09:33 -0000 MIME-Version: 1.0 Date: Mon, 24 May 2021 13:09:21 +0300 From: Alexey Izbyshev To: musl@lists.openwall.com User-Agent: Roundcube Webmail/1.4.4 Message-ID: <985e15962c164eb3076752d6ee4c05fe@ispras.ru> X-Sender: izbyshev@ispras.ru Content-Type: multipart/mixed; boundary="=_b3ce42d8791b66166be2146acc561933" Subject: [musl] Potentially infinite loop in posix_spawn'ed child --=_b3ce42d8791b66166be2146acc561933 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed 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. A test case is attached. It overrides execve() to abuse it as a callback, avoiding reliance on timings. 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. Alexey --=_b3ce42d8791b66166be2146acc561933 Content-Transfer-Encoding: base64 Content-Type: text/x-c; name=test.c Content-Disposition: attachment; filename=test.c; size=440 I2luY2x1ZGUgPGVycm5vLmg+CiNpbmNsdWRlIDxzaWduYWwuaD4KI2luY2x1ZGUgPHNwYXduLmg+ CiNpbmNsdWRlIDx1bmlzdGQuaD4KCnN0YXRpYyBpbnQgcFsyXTsKCmludCBleGVjdmUoY29uc3Qg Y2hhciAqcGF0aCwgY2hhciAqY29uc3QgYXJndltdLCBjaGFyICpjb25zdCBlbnZwW10pIHsKICBj bG9zZShwWzFdKTsKICBraWxsKGdldHBwaWQoKSwgU0lHS0lMTCk7CiAgcmVhZChwWzBdLCAmKGNo YXIpezB9LCAxKTsKICBlcnJubyA9IEVOT0VOVDsKICByZXR1cm4gLTE7Cn0KCmludCBtYWluKGlu dCBhcmdjLCBjaGFyICphcmd2W10sIGNoYXIgKmVudnBbXSkgewogICAgc2lnbmFsKFNJR1BJUEUs IFNJR19JR04pOwogICAgcGlwZShwKTsKICAgIHBvc2l4X3NwYXduKDBMLCAiL25vbi1leGlzdGlu ZyIsIDBMLCAwTCwgYXJndiwgZW52cCk7CiAgICByZXR1cm4gMDsKfQo= --=_b3ce42d8791b66166be2146acc561933--