This PR adds a new session type, which is a VNC session using a
Unix Domain Socket connection rather than a TCP connection.
This is necessary for FIPS_based deployments using VNC, as the classic
VNC password algorithm is not supported by FIPS
cppcheck 2.17.0 adds checks that a NULL pointer returned from malloc() and
calloc() is not used.
We do this quite a lot.
I've addressed this by adding functions g_malloc_nofail() and
g_calloc_nofail() which either allocate memory or abort.
functions are now called in places where we are not making these
checks.
Many of these checks are in test programs or example programs.
I've modified the list16 module to handle out-of-memory conditions.
Coverity has generated a number of 'Data race condition' and 'Double
lock' false positives. A lot of these seem to be caused by the NULL
guard in tc_mutex_unlock() not being paired with a NULL guard in
tc_mutex_lock(). This PR adds a NULL guard to tc_mutex_lock().
It should be noted, that on Linux at least, passing NULL to
tc_mutex_lock() causes a segfault. We clearly aren't doing this at the
moment, or we'd know about it. A log message is generated if a NULL
call is made, rather than failing silently.
This Coverity issue was encountered in a private build, but does not
appear to be in the Github CI build. Coverity is suspecting a copy-paste
betweem these lines in sound.c:-
1838: xstream_copyin(s, &g_stream_inp->data[g_stream_inp->size - g_bytes_in_stream], i);
1844: xstream_copyin(s, &g_stream_inp->data[g_stream_inp->size - g_bytes_in_stream], g_bytes_in_stream);
An inspection of the code shows this to bre a false positive
Coverity seems to have some problems with the loop(s) copying data from
one socket to another, in that it assume that eventually an integer
overflow will occur. It's not obvious why this should be flagged, but
this seems likely to be a false positive.
This commit avoids the integer issue by using a simple pointer + count
mechanism.
The socket copy code has been placed in a separate function - before it
was duplicated. Minor fixes have been made to error reporting around the
connection code.
We found during deployment that it is possible for some configurations
to have the build-time noopenh264 library installed, rather than the
openh264 library. This causes a failure which is difficult to diagnose.
The automated Coverity scan does not currently include neutrinordp
Two problems fixed:-
1) MAX_STATIC_CHANNELS at 31 is bigger than freerdp->sessings->channels
(16)
2) pamusername in the mod parameters is assumed to be 256 bytes when
it is written to.
matt335672