Re: kern/60962: fork and spawn read p_pgrp without proc_lock

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

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

From: Robert Elz <kre%munnari.OZ.AU@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc: 
Subject: Re: kern/60962: fork and spawn read p_pgrp without proc_lock
Date: Thu, 05 Nov 2026 07:10:17 +0700

 It looks to me there's an inherent race in the situation described,
 anyway, given the 2 threads running, one doing a fork() the other
 setsid() or setpgid(), the situation described
 
 	1. fork in one thread
 	2. setsid/setpgid in another thread
 	3. ???
 
 might just as easily be
 
 	1. setsid/setpgid in one thread
 	2. fork in another thread
 	3. ???
 
 and I don't believe
 
 	4. profit!
 
 applies at all.   This is a simple code bug in the application.
 If it cares what sid or pgrp the child gets, it shouldn't be
 altering those things at or around the time of the fork().
 
 Further, I don't think the change you made really alters anything,
 or not anything significant, if anything it makes it slightly more
 likely that the race will go the way of the fork'd child getting the
 pgrp from after the change (but obviously can't guarantee that, as in
 the first of the two scenarios above, 1 might be finished before 2 starts).
 
 That is unless you're imagining some kind of corruption if the code writing
 to p_pgrp can somehow mangle the value read from it by the copy.
 At the time the memcpy() is done, the target process (the one truly
 vulnerable here) doesn't yet exist as far as the rest of the kernel
 can tell (not yet linked anywhere), so nothing needs to be locked
 to alter it.
 
 kre