[2584] in Kerberos-V5-bugs
krb5-libs/301: gssrpc coredumps in recvmsg() [post-1.0]
daemon@ATHENA.MIT.EDU (tlyu@MIT.EDU)
Wed Dec 18 02:42:09 1996
Resent-From: gnats@rt-11.MIT.EDU (GNATS Management)
Resent-To: krb5-unassigned@RT-11.MIT.EDU
Resent-Reply-To: krb5-bugs@MIT.EDU, tlyu@MIT.EDU
Date: Wed, 18 Dec 1996 02:41:52 -0500
From: tlyu@MIT.EDU
Reply-To: tlyu@MIT.EDU
To: krb5-bugs@MIT.EDU
>Number: 301
>Category: krb5-libs
>Synopsis: gssrpc coredumps in recvmsg()
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: krb5-unassigned
>State: open
>Class: sw-bug
>Submitter-Id: unknown
>Arrival-Date: Wed Dec 18 02:42:01 EST 1996
>Last-Modified:
>Originator: Tom Yu
>Organization:
mit
>Release: post-1.0
>Environment:
System: SunOS tesla-coil 5.4 Generic_101945-37 sun4m sparc
>Description:
I found this on the mainline; don't panic...
Basically the rpc unit tests fail due to a coredump deep in the rpc
library.
Core was generated by `./server -u'.
Program terminated with signal 11, Segmentation fault.
[spewage deleted]
#0 0xef5aa710 in recvmsg ()
(gdb) bt
#0 0xef5aa710 in recvmsg ()
#1 0xef791ad0 in svcudp_recv (xprt=0x220f8, msg=0xefffe980)
at ../../../src/lib/rpc/svc_udp.c:188
#2 0xef78d688 in svc_getreqset (readfds=0xefffea28)
at ../../../src/lib/rpc/svc.c:430
#3 0xef7906e8 in svc_run () at ../../../src/lib/rpc/svc_run.c:69
#4 0x11244 in main (argc=0, argv=0xefffebac)
at ../../../../src/lib/rpc/unit-test/server.c:120
(gdb) up
#1 0xef791ad0 in svcudp_recv (xprt=0x220f8, msg=0xefffe980)
at ../../../src/lib/rpc/svc_udp.c:188
188 rlen = recvmsg(xprt->xp_sock, &dummy, MSG_PEEK);
(gdb) info locals
dummy = {msg_name = 0x221", msg_namelen = 16, msg_iov = 0x0,
msg_iovlen = 0, msg_accrights = 0x0, msg_accrightslen = 0}
su = (struct svcudp_data *) 0x22150
xdrs = (XDR *) 0x22158
rlen = 0
reply = 0x0
replylen = 0
diassembling a bit...
0xef5aa66c <recvmsg>: save %sp, -184, %sp
0xef5aa670 <recvmsg+4>: st %i2, [ %fp + 0x4c ]
0xef5aa674 <recvmsg+8>: mov 0xc, %l3
0xef5aa678 <recvmsg+12>: ld [ %i1 + 0xc ], %o0
0xef5aa67c <recvmsg+16>: cmp %o0, 1
0xef5aa680 <recvmsg+20>: ble,a 0xef5aa70c <recvmsg+160>
0xef5aa684 <recvmsg+24>: ld [ %i1 + 8 ], %i3
0xef5aa688 <recvmsg+28>: clr %i4
0xef5aa708 <recvmsg+156>: nop
0xef5aa70c <recvmsg+160>: ld [ %i1 + 8 ], %l5
0xef5aa710 <recvmsg+164>: ld [ %i3 + 4 ], %i3
0xef5aa714 <recvmsg+168>: ld [ %l5 ], %l5
0xef5aa718 <recvmsg+172>: call 0xef5bcda0 <.L670+67820>
[disclaimer... I'm not that clueful about sparc assembler...]
Here I'm assuming %i0 gets the first arg, %i1 gets the second, etc.,
thus %i1 + 0xc is &msg->msg_iovlen, and %o0 gets msg->msg_iovlen == 0.
I'm guessing that there are one or two jump slots after the ble
instruction, so that %i3 gets msg->msg_iov, which is NULL. This makes
sense that the fault would occur on the "ld [ %i3 + 4 ], %i3".
(gdb) p $i0
$19 = 4
(gdb) p (char*)$i1
$21 = 0xefffe3f8 ""
(gdb) p $i2
$22 = 2
(gdb) p $i3
$23 = 0
(gdb) up
#1 0xef791ad0 in svcudp_recv (xprt=0x220f8, msg=0xefffe980)
at ../../../src/lib/rpc/svc_udp.c:188
188 rlen = recvmsg(xprt->xp_sock, &dummy, MSG_PEEK);
(gdb) p &dummy
$14 = (struct msghdr *) 0xefffe3f8
(gdb) p xprt->xp_sock
$24 = 4
Anyway, it does seem to point rather strongly in favor of the
conclusion that recvmsg() doesn't check to see if msg->msg_iov is a
NULL pointer, or if msg->msg_iovlen is zero.
>How-To-Repeat:
Try running make check in lib/rpc.
>Fix:
* Pester Sun about recvmsg() being broken. (yeah, right) It
is not clear that they're at fault; the manpage doesn't say what
recvmsg() does if it gets a NULL msg->msg_iovec.
* Fix svcudp_recv() so that it actually passes an iovec.
>Audit-Trail:
>Unformatted:
