> On May 19, 2026, at 1:35 PM, Robert Elz via gnats <gnats-admin%netbsd.org@localhost> wrote: > > 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. 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 the vforked() child. christos
Attachment:
signature.asc
Description: Message signed with OpenPGP