I'm looking at 1.4.1 sources, so if these have been fixed elsewhere,
please let me know.

I've noticed that memory managment in some parts of the rpc framework
in src/lib/libc/rpc is potentially leaky.

All implementations of svc_getargs() seem to blindly call the
associated xdr function to decode the arguments, but without freeing
any memory that might be allocated by that xdr function on error.  I
believe this means that a malicious client may send a carefully
constructed corrupt rpc call that will cause an rpc server to allocate
a potentially arbitrary amount of memory and leak it.

Likewise, there is a call to xdr_replymsg in all the client
implementations.  However, in all instances of clnt_call() other than
clnttcp_call(), there appears to be explicit freeing of the
potentially partially decoded rpc_msg, with the explicit purpose of
avoiding leaks.  For some reason, this is not present in
clnttcp_call().  Whether this inconsistency is due to the unlikelyhood
of buggy or malicious rpc servers is not clear.

Additionally, clnttcp_call() seems to deal with the results of a call
separately, and needs an additional call to free the results in case
the xdr function for the results fails.

It is debatable whether to put the fixes to free xdr-allocated memory
in clnt_call() and svc_getargs() or to put them in the rpcgen-created
code.  In my opinion, it may be safest to put them in the rpc library
code itself.  On the other hand, the xdr functions that allocate
memory do so only if passed null pointers, and it is conceivable that
code not generated by rpgen may populate the pointers prior to calling
either clnt_call() or svc_getargs(), resulting in a potential
double-free situation.  (rpcgen-created code appears to memset() the
args or result structures, resulting in null pointers passesd to the
xdr functions.)  We may not necessarily care about code not produced
with rpcgen explicitly setting pointers in structures passed through
to xdr fuctions, though.

---Tom