[grsec] pid randomization problem - process won't execute and will return zero value

[John Logsdon]

Funny that - with 1 in /proc/sys/kernel/grsecurity/rand_pids (I've just
checked) I had this running for ages and never got a clash
(2.6.11.12-grsec, PE2650).

Maybe you have to have a lot of other processes running and therefore
forking as well - the system wasn't busy at the time.  Or it was just
chance.


John Logsdon                               "Try to make things as simple
Quantex Research Ltd, Manchester UK         as possible but not simpler"
j.logsdon at quantex-research.com              a.einstein at relativity.org
+44(0)161 445 4951/G:+44(0)7717758675       www.quantex-research.com


On Tue, 16 Aug 2005, Brad Spengler wrote:

> > With zero in /proc/sys/kernel/grsecurity/rand_pids the
> > cycle doesn't break.
> 
> I'm able to duplicate the problem as well.  It is definitely a grsec 
> bug.  The problem is that p->pid is set in kernel/fork.c much before it 
> is inserted into the task list (which makes sense, since choosing the 
> pid later on in the process would make fork bombs much more effective), 
> but when we check to see if a pid is in use, we obviously can only check 
> the ones that already exist in the task list, not those that have had 
> their pids allocated but are waiting on some lock to be inserted into 
> the task list.  This isn't a problem for the default Linux, because as 
> it increments pids, it's impossible to have 65536 forks queued up so 
> that a pending pid would be reused.  I've yet to implement the correct 
> solution to the problem, but it will most likely involve a list of those 
> pending processes, so that I can check them in addition to those already 
> in the task list.
> 
> -Brad
> _______________________________________________
> grsecurity mailing list
> grsecurity at grsecurity.net
> http://grsecurity.net/cgi-bin/mailman/listinfo/grsecurity
>