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

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    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 something
needs to send that signal to a child process, immediately (or very close after)
that child has forked.   If your code had not trapped ALRM for example, and
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 - seemingly
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 easy
(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