>Number:         10683
>Category:       bin
>Synopsis:       rpcbind coredumps when trying to update nis info
>Confidential:   no
>Severity:       serious
>Priority:       high
>Responsible:    bin-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Wed Jul 26 02:51:00 PDT 2000
>Closed-Date:
>Last-Modified:
>Originator:     Rene Hexel
>Release:        NetBSD-1.5_ALPHA as of 2000-07-25
>Organization:
	
>Environment:
System: NetBSD config 1.5_ALPHA NetBSD 1.5_ALPHA (CONFIG) #3: Tue Jul 25 13:58:24 CEST 2000 rh@config:/home/src/sys/src/sys/arch/i386/compile/CONFIG i386

>Description:
	rpcbind tends to crash in conjunction with nis.  While this
appens randomly during normal nis (yp) operations, like passwd lookup,
it is almost always reproducible when updating yp data (see below).
In these cases, rpcbind core-dumps and exits:


(gdb) backtrace
#0  0x480dd800 in strcmp ()
#1  0x804a952 in rpcbind_get_conf (netid=0x0) at check_bound.c:223
#2  0x804b264 in rpcbproc_getaddr_4_local (arg=0xbfbfcac8, rqstp=0xbfbfcff0, transp=0x8064b80, rpcbversnum=4) at rpcb_svc_4.c:269
#3  0x804b18b in rpcb_service_4 (rqstp=0xbfbfcff0, transp=0x8064b80) at rpcb_svc_4.c:225
#4  0x480c17d9 in _svc_getreq_common ()
#5  0x480c1993 in svc_getreq_poll ()
#6  0x804ec4b in my_svc_run () at rpcb_svc_com.c:1130
#7  0x804b97a in main (argc=3, argv=0xbfbfd8c8) at rpcbind.c:199
#8  0x804a381 in ___start ()


	Apparently, strcmp() gets called with a NULL second parameter from
rpcbind_get_conf() at check_bound.c:223, because transp->xp_netid is NULL in
rpcbproc_getaddr_4_local() at rpcb_svc_4.c:269 (this is when compiled with
RPCBIND_DEBUG defined, otherwise it coredumps and exits somewhere further
down).


>How-To-Repeat:
	Set up a yp server, then run the following programs (or let them
be started through rc):

# rpcbind -l
# ypserv -d
# ypbind
# rpc.yppasswdd

	Then, goto /var/yp, do a 'make' and wonder why it never returns:

# cd /var/yp
# make

	Check your running processes and discover that 'rpcbind' has
coredumped.


>Fix:
	A fix probably has to be twofold: first, rpcbind needs to do
some sanity checking of the parameters it receives from any caller.
Second, whatever program is responsible for that bogus transp->xp_netid,
be it rpcbind itself or any nis program (yppush?) needs to be fixed.
>Release-Note:
>Audit-Trail:
>Unformatted: