On 13 Jun, Robert Watson wrote: > > On Sun, 13 Jun 2004, Tim Robbins wrote: > >> > Well, this is certainly a NULL pointer dereference in the sysctl code >> > exporting file descriptor information to user space (perhaps for fstat?). >> > The question is what is NULL. It looks like you have a dump -- could you >> > convert sysctl_kern_file+0x105 to a line number? It's likely that it is >> > line 2346 of kern_descrip.c, which follows the process pointer to its >> > ucred. If so, could you use gdb on the dump to inspect *p? >> >> ISTR he included the output of "print *p" on his web page. >> >> I think the problem here is that we put processes onto the allproc list >> in fork1() before they're properly initialised (or we unlock the allproc >> sx too early.) > > Hmm. I noticed, though, that p_flag is set to P_CONTROLT and P_WEXIT, so > my initial suspicion was actually exit1(). My initial suspicion was the kern_wait() code that sets p_ucred to NULL, but the process has been removed from allproc by that point. It also looks to me like fork1() is the culprit. The new process is put on allproc at line 410, allproc_lock is dropped at line 412, the process is locked at line 474, p_flag is cleared at line 509, and p_ucred is set at line 521. Another clue is the p_state is PRS_NEW. Based on this, I'd guess that sysctl_kern_file() is stumbling across this process while fork1() is somewhere between lines 412 and 474. I think the bzero()/bcopy() stuff has to happen before the new process is added to allproc and p_ucred is set, otherwise there is the possibility of an information leak between jails (p_comm[], etc.). Why is sched_fork() called so early?Received on Sun Jun 13 2004 - 04:47:15 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:57 UTC