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

["Christos Zoulas via gnats" <gnats-admin%NetBSD.org@localhost>]

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

From: Christos Zoulas <christos%zoulas.com@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc: kre%netbsd.org@localhost,
 gnats-admin%netbsd.org@localhost,
 netbsd-bugs%netbsd.org@localhost,
 campbell+netbsd%mumble.net@localhost
Subject: Re: bin/60275: sh(1): race condition in signal handling on background
 subshell fork
Date: Tue, 19 May 2026 14:30:10 -0400

 --Apple-Mail=_E6CB0301-5BD8-4DEF-B105-E4ACCB6C8889
 Content-Transfer-Encoding: quoted-printable
 Content-Type: text/plain;
 	charset=utf-8
 
 
 
 > On May 19, 2026, at 1:35=E2=80=AFPM, Robert Elz via gnats =
 <gnats-admin%netbsd.org@localhost> wrote:
 >=20
 > The following reply was made to PR bin/60275; it has been noted by =
 GNATS.
 >=20
 > From: Robert Elz <kre%munnari.OZ.AU@localhost>
 > To:=20
 > Cc: gnats-bugs%netbsd.org@localhost, netbsd-bugs%netbsd.org@localhost
 > Subject: Re: bin/60275: sh(1): race condition in signal handling on =
 background subshell fork
 > Date: Wed, 20 May 2026 00:31:57 +0700
 >=20
 > It turns out there is an, essentially untestable, problem remaining =
 with the
 > previous fix.   It still requires a signal to be delivered to a child
 > immediately after a fork() which the parent had trapped, but this =
 issue
 > can only arrive when vfork() is used instead of fork() - hence the =
 parent
 > process cannot be the source of the signal (by the time it is running
 > again after a vfork() too much time would have passed for the issue to
 > occur) which is what makes in essentially impossible to test - the =
 time
 > window is very short for the signal to arrive at the child, and the =
 parent
 > has no good means to inform anything else, precisely enough, when the =
 signal
 > would need to be sent.   Of course, one day, it would occur in the =
 wild...
 >=20
 > The effect this time would not be for the signal to be mishandled in =
 the
 > child, the previous fix(es) have dealt with that issue, rather in this =
 case
 > the parent would believe that it had also received the signal, and =
 thus
 > (eventually, that is, after it has finished cleaning up from starting =
 the
 > child, etc, and is ready for whatever comes next) execute the trap - =
 that
 > is, the parent running a trap as if it received the signal, where the =
 signal
 > was only delivered to the child.    (The signal handler, which does =
 little,
 > as is required of all well behaved signal handlers, does very little, =
 just
 > remembers that the signal occurred ... but in a vfork'd child that =
 must not
 > be allowed to happen, unplanned alterations to parent memory are =
 prohibited.)
 >=20
 > I believe this problem has existed as long as vfork() use has been in =
 the
 > shell, though most likely has never caused a problem, and perhaps =
 never
 > would, but there is clearly the potential for it to happen, however =
 small.
 >=20
 > Because of this, I won't be requesting pullups for at least another =
 day or
 > two - while there's no way I can think of to actually test for this, =
 which
 > would ever prove anything (with extreme luck, the issue might be =
 demonstrated
 > to occur, but nothing I can think of, can ever, via testing, show it =
 is fixed)
 > we do at least need to make sure that the fix for the issue causes no =
 other
 > problems.   The fix will be committed in a few hours, after a local =
 full
 > build, and ATF test run, then it needs to be exposed to the world for =
 a
 > while.
 
 
 vfork() is temperamental. Check out the tcsh code sh.sem.c in particular
 
 #if defined(SUNOS4) || defined(DGUX) || defined(hp800) || (SYSVREL > 3 =
 && defined(VFORK))
 # define SAVESIGVEC
 #endif /* SUNOS4 || DGUX || hp800 || SVR4 & VFORK */
 
 and
 
 savesigvec() macros.
 
 In some implementations the signal disposition is shared between parent =
 and=20
 the vforked() child.
 
 christos
 
 
 
 --Apple-Mail=_E6CB0301-5BD8-4DEF-B105-E4ACCB6C8889
 Content-Transfer-Encoding: 7bit
 Content-Disposition: attachment;
 	filename=signature.asc
 Content-Type: application/pgp-signature;
 	name=signature.asc
 Content-Description: Message signed with OpenPGP
 
 -----BEGIN PGP SIGNATURE-----
 Comment: GPGTools - http://gpgtools.org
 
 iF0EARECAB0WIQS+BJlbqPkO0MDBdsRxESqxbLM7OgUCagysMgAKCRBxESqxbLM7
 Oj7uAKCcyV4HwkXxuzQooGkeNnR0MeWzfwCePQvIq9tY5iwliwq7B6RHuPjUJwk=
 =gffm
 -----END PGP SIGNATURE-----
 
 --Apple-Mail=_E6CB0301-5BD8-4DEF-B105-E4ACCB6C8889--