Allows us to compare our computed congestion window with the
underlying one used by the TCP layer.

Refine the previous method by interpolating the values we need.
This reduces the effect of the problem that we cannot send enough
ping packets.

It's a general function and it's better to have that particular
complexity in its own place.

This reduces the data sent, and avoids any problems with the
client corrupting it.

We shouldn't unconditionally remove the server side cursor just
because the client supports client side cursors. We need to also
check that the client fulfills the other criteria for taking over
the cursor.

In most cases we will send an update at the end of processing client
messages so these extra calls only slow things down. Server initiated
events still need an explicit call though.

Improve the tracking of what cursor we've sent to the client to make
sure the initial cursor is sent properly. We previously tried to infer
this information based on if we've rendered a server side cursor or
not. This logic broke down if things triggered before we've sent the
first update to the client.

Add a Configuration::removeParam to support such cases.

This makes it possible to create a derived class from Socket which is
not TCP based, without having VNCSConnectionST.cxx trying to call
setsockopt() on a non-socket.

There is a problematic corner case where an application is updating
at exactly the same rate that we're sending update. In that case we
may miss updates regularly, getting a very uneven final frame rate.
Avoid this by introducing a slight offset when we start updating.

The logic got inverted resulting in the cursor being sent needlessly
whenever the cursor moved.

Include the type of exception in the string generated by each
subclass. Also simplify the constructs to what is needed.

It was moved to the common code in f8e3b34c6, but it was unreliable
because the state could sometimes get out of sync. Push it back in
to Xvnc since it isn't necessarily something all servers will have.

Don't touch the existing value or we might mess it up when we avoid
division by zero.

The buffer is considered changed right away, so we might not get any
add_changed() calls to trigger a start of the timer.

It was only used by WinVNC, so push it there instead.

Don't force users of these headers to squash compiler
warnings about unused arguments, annotate with __unused_attr.

Otherwise the client can end up with two visible cursors.

In case the server is a front-end to multiple systems and needs to
know which system we're after.

The sub-modules generally provide a better description than just the
short security method name.

Indicate to the user how secure the transport channel is so they
can avoid entering their password for untrusted sites.

This makes it easier to provide more sane events to the backend code
even with crazy clients.

As a result we weren't overloading properly.

This adds the basic infrastructure and handshake for the QEMU
Extended Key Events extension. No viewer or server makes use of
the extra functionality yet though.

Based on QEMU's behaviour.

Some servers respect the ordering of pseudo-encodings as well, so
make sure we list the best one first.

Fixes:

/home/shade/dev/tigervnc/common/rfb/util.cxx:55:13: error: comparison of unsigned expression < 0 is always false [-Werror,-Wtautological-compare]
    if (len < 0) {
        ~~~ ^ ~
1 error generated.

Clang complains loudly about this with Wformat=2, so add
a __printf_attr to help out.

Fixes:

/home/shade/dev/tigervnc/common/rfb/Logger.cxx:48:35: error: format string is not a string literal [-Werror,-Wformat-nonliteral]
  vsnprintf(buf1, sizeof(buf1)-1, format, ap);
                                  ^~~~~~
1 error generated.

InputHandler declares the second parameter of clientCutText
as an int.

Fixes:

/home/shade/dev/tigervnc/common/rfb/CMsgWriter.h:60:18: error: 'rfb::CMsgWriter::clientCutText' hides overloaded virtual function [-Werror,-Woverloaded-virtual]
    virtual void clientCutText(const char* str, rdr::U32 len);
                 ^
/home/shade/dev/tigervnc/common/rfb/InputHandler.h:36:18: note: hidden overloaded virtual function 'rfb::InputHandler::clientCutText' declared here: type mismatch at 2nd parameter ('int' vs 'rdr::U32' (aka 'unsigned int'))
    virtual void clientCutText(const char* str, int len) {}
                 ^

Clang doesn't like when struct and class are used to refer
to the same thing interchangeably.

Fixes all instances of:

In file included from /home/shade/dev/tigervnc/common/rfb/CConnection.cxx:29:
In file included from /home/shade/dev/tigervnc/common/rfb/CConnection.h:28:
/home/shade/dev/tigervnc/common/rfb/DecodeManager.h:35:3: error: class 'Exception' was previously declared as a struct [-Werror,-Wmismatched-tags]
  class Exception;
  ^
/home/shade/dev/tigervnc/common/rdr/Exception.h:32:10: note: previous use is here
  struct Exception {
         ^
/home/shade/dev/tigervnc/common/rfb/DecodeManager.h:35:3: note: did you mean struct here?
  class Exception;
  ^~~~~
  struct
/home/shade/dev/tigervnc/common/rfb/DecodeManager.h:43:3: error: class 'Rect' was previously declared as a struct [-Werror,-Wmismatched-tags]
  class Rect;
  ^
/home/shade/dev/tigervnc/common/rfb/Rect.h:68:10: note: previous use is here
  struct Rect {
         ^
/home/shade/dev/tigervnc/common/rfb/DecodeManager.h:43:3: note: did you mean struct here?
  class Rect;
  ^~~~~
  struct

Fix warnings emitted by Clang:

/home/shade/dev/tigervnc/common/rdr/FdInStream.h:30:9: error: 'rdr::FdInStreamBlockCallback' has virtual functions but non-virtual destructor [-Werror,-Wnon-virtual-dtor]
  class FdInStreamBlockCallback {
        ^
In file included from /home/shade/dev/tigervnc/common/network/TcpSocket.cxx:44:
In file included from /home/shade/dev/tigervnc/common/network/TcpSocket.h:31:
/home/shade/dev/tigervnc/common/network/Socket.h:82:9: error: 'network::ConnectionFilter' has virtual functions but non-virtual destructor [-Werror,-Wnon-virtual-dtor]
  class ConnectionFilter {
        ^
..etc

Fix the following warnings emitted by Clang:

/home/shade/dev/tigervnc/common/rfb/Configuration.h:164:18: note: hidden overloaded virtual function 'rfb::VoidParameter::setParam' declared here: different number of parameters (0 vs 1)
    virtual bool setParam();
                 ^
/home/shade/dev/tigervnc/common/rfb/Configuration.h:256:18: error: 'rfb::BinaryParameter::setParam' hides overloaded virtual function [-Werror,-Woverloaded-virtual]
    virtual void setParam(const void* v, int l);
                 ^
/home/shade/dev/tigervnc/common/rfb/Configuration.h:164:18: note: hidden overloaded virtual function 'rfb::VoidParameter::setParam' declared here: different number of parameters (0 vs 2)
    virtual bool setParam();

Width and height of a cursor are received as U16 from network. Accepting full range of U16 values can cause integer overflows in multiple places.

The worst is probably VLA in CMsgReader::readSetXCursor:
  rdr::U8 buf[width*height*4];

The width*height*4 can be too big to fit on stack or it can overflow into negative numbers. Both cases are undefined behaviour. Following writes to buf can overwrite other data on stack.

Setting the limit to 1024 which should be still more than enough.

Unlimited ulen and plen can cause various security problems:
  * Overflow in `is->checkNoWait(ulen + plen)` causing it to contine when there is not enough data and then wait forever.
  * Overflow in `new char[plen + 1]` that would allocate zero sized array which succeeds but returns pointer that should not be written into.
  * Allocation failure in `new char[plen + 1]` from trying to allocate too much and crashing the whole server.

All those issues can be triggered by a client before authentication.

Currently it proceeds only if there aren't enough data in queue and then it blocks waiting.
Also the required amount to receive from network is (ulen + plen), not (ulen + plen + 2).

This allowed not authenticated clients to deny service to everyone.

Otherwise it gets leaked which would allow even not authenticated clients to exhaust server memory.

If client sent fence with some data, followed by fence with no data (length 0), the original fence data were freed, but the pointer kept pointing at them. Sending one more fence would attempt to free them again.