The mapping was a little messy and made some assumptions which we get
away with but should be made more robust.
The first IOV length was never correctly verified against the size
of the transport status and if it was contained completely in the first
page. There was an assumption that this was always the case but the
Windows client would send pings containing IOVs of buffers on the stack
and as such could easily break the VMX.
The adjust of the packet IOVs by the VMCI code to skip over the VMCI
transport status before passing to the HGFS server to process has also
been cleaned up. As has the restoration of the packet IOVs on final
processing to access the packet VMCI transport status to set complete.
In order to simplify this the HgfsPacket structure now contains an IOV
field for the transport channel to use which holds the start of the
VMCI channel transport status IOVs. This is then used to restore once
the HGFS server has completed processing and the transport channel is
doing the final send processing.
Signed-off-by: Dmitry Torokhov <dtor@vmware.com>
size_t replyPacketSize;
Bool replyPacketIsAllocated;
+ /* Iov for the packet private to the channel. */
+ HgfsVmxIov channelIov[2];
+
uint32 iovCount;
HgfsVmxIov iov[1];