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: 
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

 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...
 
 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.)
 
 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.
 
 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.
 
 kre