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

[John Logsdon]

Belay that!  I had forgotten I had rebooted recently.  Yes it does clash.

John

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 Fri, 19 Aug 2005, John Logsdon wrote:

> 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
> > 
> 
> _______________________________________________
> grsecurity mailing list
> grsecurity at grsecurity.net
> http://grsecurity.net/cgi-bin/mailman/listinfo/grsecurity
>