An exception thrown inside UnicastServerRef.dispatch is caught without being
rethrown to the caller (Transport.serviceCall). The caller then assumes
that the call has completed and continues to read from the connection.
TCPTransport.handleMessages then reads from the same connection and assumes
that the next data read are an opcode from the RMI protocol. If the
exception was thrown before the call was completely unmarshalled, then those
assumptions are false; handleMessages is reading and interpreting garbage
from the connection stream. This could lead to a method being invoked
(if actively exploited). There's no direct security hole, but the risk is
that a security policy (e.g. an RMI protocol analyzer which expects to parse
the methods called and filter out bad ones) could depend on handleMessages
doing the right thing here.