From owner-freebsd-hackers  Fri Oct 23 22:05:35 1998
Return-Path: <owner-freebsd-hackers@FreeBSD.ORG>
Received: (from majordom@localhost)
          by hub.freebsd.org (8.8.8/8.8.8) id WAA15773
          for freebsd-hackers-outgoing; Fri, 23 Oct 1998 22:05:35 -0700 (PDT)
          (envelope-from owner-freebsd-hackers@FreeBSD.ORG)
Received: from gatekeeper.tsc.tdk.com (gatekeeper.tsc.tdk.com [207.113.159.21])
          by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id WAA15768
          for <hackers@FreeBSD.ORG>; Fri, 23 Oct 1998 22:05:33 -0700 (PDT)
          (envelope-from gdonl@tsc.tdk.com)
Received: from sunrise.gv.tsc.tdk.com (root@sunrise.gv.tsc.tdk.com [192.168.241.191])
	by gatekeeper.tsc.tdk.com (8.8.8/8.8.8) with ESMTP id WAA22989;
	Fri, 23 Oct 1998 22:04:58 -0700 (PDT)
	(envelope-from gdonl@tsc.tdk.com)
Received: from salsa.gv.tsc.tdk.com (salsa.gv.tsc.tdk.com [192.168.241.194])
	by sunrise.gv.tsc.tdk.com (8.8.5/8.8.5) with ESMTP id WAA10913;
	Fri, 23 Oct 1998 22:04:57 -0700 (PDT)
Received: (from gdonl@localhost)
	by salsa.gv.tsc.tdk.com (8.8.5/8.8.5) id WAA22700;
	Fri, 23 Oct 1998 22:04:55 -0700 (PDT)
From: Don Lewis <Don.Lewis@tsc.tdk.com>
Message-Id: <199810240504.WAA22700@salsa.gv.tsc.tdk.com>
Date: Fri, 23 Oct 1998 22:04:55 -0700
In-Reply-To: Don Lewis <Don.Lewis@tsc.tdk.com>
       "Re: question about getsid()" (Oct 23,  2:51am)
X-Mailer: Mail User's Shell (7.2.6 alpha(3) 7/19/95)
To: Don Lewis <Don.Lewis@tsc.tdk.com>,
        "Jukka A. Ukkonen" <jau@jau.tmt.tele.fi>, hackers@FreeBSD.ORG
Subject: Re: question about getsid()
Sender: owner-freebsd-hackers@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

On Oct 23,  2:51am, Don Lewis wrote:
} Subject: Re: question about getsid()
} On Oct 21,  4:19pm, "Jukka A. Ukkonen" wrote:
} } Subject: question about getsid()
} 
} } 	When looking at the 3.0 getsid() code in kern_prot.c I became
} } 	a little hesitant about whether the following code will always
} } 	work...
} } 
} } int
} } getsid(p, uap)
} }         struct proc *p;
} }         struct getsid_args *uap;
} } {
} }         if (uap->pid == 0)
} }                 goto found;
} } 
} }         if ((p == pfind(uap->pid)) == 0)
} }                 return ESRCH;
} } found:
} }         p->p_retval[0] = p->p_pgrp->pg_session->s_leader->p_pid;
} }         return 0;
} } }
} } 
} } 	What will happen if the process leader has already died?
} } 	Will the original session leader's process struct still be
} } 	around available for reference or will the code fail?
} 
} It looks to me like the code will follow a stale pointer off into
} space.  I suspect the result will be a bogus return value rather
} than a panic.

I looked at this some more and it appears I was mistaken.  When the
session leader exits, exit1() in kern_exit.c does
	sp->s_leader = NULL;
This means that getsid() will dereference the NULL pointer and panic
the system.

getsid() needs to verify s_leader is not NULL before dereferencing it,
but what should getsid() return if there is no session leader?


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message