mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Alexey Izbyshev <izbyshev@ispras.ru>
To: musl@lists.openwall.com
Subject: Re: [musl] Potentially infinite loop in posix_spawn'ed child
Date: Thu, 29 Feb 2024 17:03:51 +0300	[thread overview]
Message-ID: <4f0953e3c103fac9cf01059781742644@ispras.ru> (raw)
In-Reply-To: <20210525143210.GH2546@brightrain.aerifal.cx>

[-- Attachment #1: Type: text/plain, Size: 1615 bytes --]

On 2021-05-25 17:32, Rich Felker wrote:
> 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.
> 
I've never sent a patch for this, doing it now.

Thanks,
Alexey

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-posix_spawn-fix-child-spinning-on-write-to-a-broken-.patch --]
[-- Type: text/x-diff; name=0001-posix_spawn-fix-child-spinning-on-write-to-a-broken-.patch, Size: 1426 bytes --]

From 36eda01dbe0a35c4c65c394723a70c2d1b75e591 Mon Sep 17 00:00:00 2001
From: Alexey Izbyshev <izbyshev@ispras.ru>
Date: Thu, 29 Feb 2024 14:13:18 +0300
Subject: [PATCH] posix_spawn: fix child spinning on write to a broken pipe
Mail-Followup-To: musl@lists.openwall.com

A child process created by posix_spawn reports errors to its parent via
a pipe, retrying infinitely on any write error to prevent falsely
reporting success. If the (original) parent dies before write is
attempted, there is nobody to report to, but the child will remain
stuck in the write loop forever if SIGPIPE is blocked or ignored.
Fix this by not retrying write if it fails with EPIPE.
---
 src/process/posix_spawn.c | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/src/process/posix_spawn.c b/src/process/posix_spawn.c
index 728551b36792..8294598bb7e3 100644
--- a/src/process/posix_spawn.c
+++ b/src/process/posix_spawn.c
@@ -4,6 +4,7 @@
 #include <unistd.h>
 #include <signal.h>
 #include <fcntl.h>
+#include <errno.h>
 #include <sys/wait.h>
 #include "syscall.h"
 #include "lock.h"
@@ -156,7 +157,11 @@ static int child(void *args_vp)
 fail:
 	/* Since sizeof errno < PIPE_BUF, the write is atomic. */
 	ret = -ret;
-	if (ret) while (__syscall(SYS_write, p, &ret, sizeof ret) < 0);
+	if (ret) {
+		int r;
+		do r = __syscall(SYS_write, p, &ret, sizeof ret);
+		while (r<0 && r!=-EPIPE);
+	}
 	_exit(127);
 }
 
-- 
2.39.2


  reply	other threads:[~2024-02-29 14:04 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-24 10:09 Alexey Izbyshev
2021-05-24 15:40 ` Szabolcs Nagy
2021-05-24 16:50   ` Alexey Izbyshev
2021-05-24 20:33 ` Rich Felker
2021-05-25  6:30   ` Alexey Izbyshev
2021-05-25 14:32     ` Rich Felker
2024-02-29 14:03       ` Alexey Izbyshev [this message]
2024-02-29 15:35         ` Rich Felker

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4f0953e3c103fac9cf01059781742644@ispras.ru \
    --to=izbyshev@ispras.ru \
    --cc=musl@lists.openwall.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).