Date: Fri, 23 Oct 1998 22:04:55 -0700 From: Don Lewis <Don.Lewis@tsc.tdk.com> To: Don Lewis <Don.Lewis@tsc.tdk.com>, "Jukka A. Ukkonen" <jau@jau.tmt.tele.fi>, hackers@FreeBSD.ORG Subject: Re: question about getsid() Message-ID: <199810240504.WAA22700@salsa.gv.tsc.tdk.com> In-Reply-To: Don Lewis <Don.Lewis@tsc.tdk.com> "Re: question about getsid()" (Oct 23, 2:51am)
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199810240504.WAA22700>