When a FreeRDP-based server tried to open a DVC, but the client answered
the DVC create request with a negative CreationStatus in the DVC create
response PDU, the server can then assume that no actual PDUs can be
received for that channel.
However, as long as the channel handle exists, FreeRDP happily forwards
any potential PDU for that handle disregarding the CreationStatus.
This is problematic, since the channel handling usually runs in its own
thread and as a result, the channel may not be destructed yet, when
receiving such stray PDU.
The PDU may be processed, even though it is not expected to be.
A situation, where this becomes problematic is the AUDIO_PLAYBACK_DVC
channel.
It may be the case, that the client answered the DVC create request
with a negative result, the server may try to close the handle and open
the static channel (RDPSND) instead, but before the server can close the
channel handle, the client actually sends PDUs regarding the format
negotiation.
In this case, the server may unintentionally already set things up,
which was not desired (the DVC is about to be closed anyway).
While this specific situation is hypothetical, since it would depend on
a malicious client, it is still possible to happen, especially since the
server implementation does not invoke the format negotiation, but
FreeRDP does it automatically, as soon as the DVC create request is
sent.
Fix this issue by discarding any data PDUs (DYNVC_DATA_FIRST and
DYNVC_DATA) of channels, that were not opened successfully.
With all calls when WTSVirtualChannelQuery returns FALSE that means that
no ppBuffer was allocated, that was not the case with class=WTSVirtualChannelReady.
Most callers were not aware of that, leading to leaks for example when the channel is
not available client-side, the patch changes that so that you have to call call WTSFreeMemory
only if WTSVirtualChannelQuery returned TRUE.
This patch does a few cleanups to allow creating TLS and DTLS contexts.
It also introduces tls_accept_ex and tls_connect_ex that can start the SSL handshake,
and it can be finished by calling tls_handshake
In case alternate shell was set to an empty string ("") the old code
would try to convert it to a WChar string. This resulted in a NULL
pointer being returned by `ConvertUtf8ToWCharAlloc` that was interpreted
as an error and the connection failed.
* Removed comments with invalid assumptions
* Added arguments to rdp_read_info_null_string to indicate if the string
is expected to be '\0' terminated and what is actually read for error
logs
Multi-transport flags must be merged between local and remote so that on both sides
we know the shared parameters. Also this patch sends multi-transport GCC block when
multi-transport is enabled.
There was still an issue left, if diff == 0 then the loop counter did
never increment.
Skip this case now completely as the memory does not need to be copied
anyway.
If source and destination buffers are equal the calculation of
'rest = num % div' is a division by zero. Avoid that by checking
explicitly for that condition.
