[RFC][PATCH] krb5 => libverto main loop

Greg Hudson ghudson at MIT.EDU
Thu Aug 25 15:17:03 EDT 2011


On Thu, 2011-08-25 at 14:21 -0400, Greg Hudson wrote:
> On another note [...]

Of course, minutes after I send the mail, I figure out that the problem
was quite shallow and I was staring at the wrong piece of code.  Here's
a list of problems:

* add_rpc_listener_fd() doesn't use VERTO_EV_FLAG_PERSIST, so only one
RPC connection is accepted and then the listener socket is closed.

* accept_rpc_connection() grabs the private data pointer from newev
before checking if newev is null.

* accept_tcp_connection() grabs the private data from the wrong event
after creating newev.

* accept_tcp_connection() grabs the private data before testing if newev
is null (if it were using the correct event pointer, this would
dereference a null pointer).

* accept_tcp_connection() closes the listener connection if it fails to
create an event for a new TPC connection.  It should close the new
socket instead.

* When an RPC connection closes, process_rpc_connection() deletes the
event which causes free_socket() to close the fd and call
svc_getreqset() on the fd to convince the RPC runtime to clear its
state.  But the RPC runtime has already closed the fd and cleared its
state (which is why the old code only did that stuff for a "forced
close" in kill_tcp_or_rpc_connection()).  This results in a null pointer
dereference.

Several of these problems were detected by the test suite.  Many of the
kadm5 and gssrpc tests only run if you have dejagnu installed, so please
make sure you have the full test suite running.
http://k5wiki.kerberos.org/wiki/Test_suite has some notes.

(The particular tests I saw problems with is conditionalized on dejagnu
being installed, even though it just needs C and Bourne shell; that's
probably a bug in the build system.)




More information about the krbdev mailing list