From owner-freebsd-arch@FreeBSD.ORG Sat Jun 26 16:38:55 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 626C316A4CE for ; Sat, 26 Jun 2004 16:38:55 +0000 (GMT) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 14B4543D5A for ; Sat, 26 Jun 2004 16:38:55 +0000 (GMT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.12.11/8.12.11) with ESMTP id i5QGchgD058377 for ; Sat, 26 Jun 2004 12:38:43 -0400 (EDT) (envelope-from robert@fledge.watson.org) Received: from localhost (robert@localhost)i5QGchKg058374 for ; Sat, 26 Jun 2004 12:38:43 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Sat, 26 Jun 2004 12:38:43 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: arch@FreeBSD.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Confusion about process states and invariants X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jun 2004 16:38:55 -0000 Over the last two weeks, I've seen several reports of panics relating to code making incorrect assumptions about process state, generally relating to the "p_ucred" pointer in new and dying processes. In particular, a number of pieces of code assume that if a process is reachable by the all process list (or other process lists), p_ucred will be valid and non-NULL if the process lock is held on the process. This results in possible NULL pointer dereferences in the PRS_NEW state, and also during the tear-down in kern_wait(). At first glance, the easy answer would appear to be "check for p_ucred to be NULL", but I'm actually of the opinion that I'd prefer we have the non-NULL p_ucred invariant actually hold true. This would permit security checks to be performed properly during those windows. I'm not very familiar with our process state and locking, but if someone with a more qualified background in that area could comment on the current issue, that would be useful. FYI, two of the reported problems were in sysctl_kern_proc() and linprocfs. One of those has been patched by checking p_ucred for NULL; the other has not. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Principal Research Scientist, McAfee Research