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.

They are created in SConnection's and CConnection's constructors but never destroyed.

There is no reason for the indirection, so lets make them direct members.

The length sent by client is U32, but is converted into int. If it was bigger than 0x7fffffff the resulting int is negative, it passes the check against maxCutText and later throws std::bad_alloc from CharArray which takes down the whole server.

All the Streaming API deals with lengths in ints, so we can't tell it to skip that big amount of data. And it is not realistic to expect more than 2GB of clipboard data anyway. So lets just throw rdr::Exception that will disconnect this client and keep the server alive.

This redesigns the old "deferred updates" mechanism in to a frame
clock that governs how often updates are sent out. The goal is still
the same, to aggregate updates and avoid pointless updates, all in
the name of efficiency. This model should however be more robust
against delays that sometimes causes us to miss the desired rate.

This is not the code path commonly used in performance sensitive
scenarios, so favour correctness over performance.

Make it a bit more readable.

Make the control flow a bit clearer.

Make sure the code deals more gracefully with timers that take a
long time to execute, and therefore might miss their deadlines.

Adds an optional graph to the viewer to display current frame rate,
pixel rate and network bandwidth. Makes it easier to debug and test
performance related issues.

Even if there are no pixels it will still trigger sanity checks
when we start throwing bogus coordinates around.

It adds a lot of noise to the debug output with little gain.

This will allow us to use better formats that preserve the entire
alpha channel.

We can no longer assume maskRect() will tolerate uncropped data.

We need to restore the previous, more complex API in order to
easily handle masks now that we no longer accept out-of-bounds
operations.

There has been multiple attempts at tricking decoders to exceed
the boundaries of the active pixel buffer. Add extra checks to
prevent such invalid access.

It can be triggered by RRE message with subrectangle out of framebuffer
boundaries. It may prevent the same kind of issue caused by evil message
from another encoding too.

The hextileDecodexx functions do not properly check for out-of-bounds writes,
which allows a malicious server to overwrite parts of the stack.

Any caller using add or remove should also be able to list the
sockets.

Some of these were excessively large because of redundant factors
in the size calculation.

These are reference counted so it is important to retain symmetry
between the calls. Failure to do so will result in bad memory access
and crashes.

168b92c broke the handling that assumes display 100 and above are
actually a port number.

Use the platform independent primitives instead.

It now does more validation, and handles unescaped IPv6 addresses
better.

We've stolen the Xregion code from libX11, so let's keep the same
header naming so that it is easier to keep things in sync.

There might be stuff lingering in the buffer simply because flush()
hasn't been called in a while, rather than because the transport is
congested.

We now get notifications when the output buffer empties, and we
already caught incoming RTT pongs, meaning we can now react at the
proper time to retry a congested update rather than use a timer.

This makes sure we keep the socket busy even if one rect takes some
time to encode.

What to do when a socket is writeable should be handled in the
RFB core code as there may be other events we want to fire off
when this happens.