Re: bin/60275 (sh(1): race condition in signal handling on background subshell fork)

["Robert Elz via gnats" <gnats-admin%NetBSD.org@localhost>]

The following reply was made to PR bin/60275; it has been noted by GNATS.

From: Robert Elz <kre%munnari.OZ.AU@localhost>
To: gnats-bugs%netbsd.org@localhost, netbsd-bugs%netbsd.org@localhost
Cc: 
Subject: Re: bin/60275 (sh(1): race condition in signal handling on background subshell fork)
Date: Tue, 19 May 2026 10:13:59 +0700

     Date:        Tue, 19 May 2026 00:53:47 +0000 (UTC)
     From:        riastradh%NetBSD.org@localhost
     Message-ID:  <20260519005347.B0AD81A923A%mollari.NetBSD.org@localhost>
 
   | Haven't tried 10 or 9 yet but I would guess the same fix is needed.
 
 Much the same certainly, this bug has been there in one form or other
 forever (ie: since sh sources 1.1).   Its form, how it affects things,
 and the actual code flow inside sh, has changed over time, but there was
 never any protection against this issue (in some versions it would have
 caused a shell core dump).
 
   | (This isn't really an exotic issue: I hit this in practice as part of
   | the automatic tests for our new repository infrastructure!
 
 30-something years of being there, and sometimes certainly causing core
 dumps, and no fixes even attempted, that to me suggests something exotic.
 
 To trigger it, the parent needs to be trapping some signal, and then somet=
 hing
 needs to send that signal to a child process, immediately (or very close a=
 fter)
 that child has forked.   If your code had not trapped ALRM for example, an=
 d
 used SIGALRM to kill the child, the issue never would have occurred.
 
 Certainly, once you have code that can trigger it, it will keep doing it,
 there just really isn't almost any code out there that does that - seeming=
 ly
 just yours.
 
 Of course, it is a bug, and should be fixed, regardless of that.
 
 I will work on pullups soon, -11 will be easy, 10 probably just about as e=
 asy
 (very little has changed in sh since -10, mostly just some bug fixes). -9 =
 I
 will need to look at more.  8 would have been a bigger issue - fortunately=
  one
 we can ignore now, and 7 I think even harder (just adapting the code, the =
 same
 mechanisms would work, but the environment to insert them in was different=
 ).
 
 kre