| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
|
|
|
| |
(cherry picked from commit 994296ebd00bb26a171febaef749d102f747c1e9)
|
|
|
|
| |
(cherry picked from commit bf0b607993b70b2f634fc7f8a30e0f955f279e5e)
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
(cherry picked from commit 923bb976c79691ff063b7ca64db72427274ecd9a)
|
|
|
|
| |
(cherry picked from commit cba5f2d99cd63d1224526c030b563899d29b8624)
|
|
|
|
| |
(cherry picked from commit 90bab337db587f6bb8643c08576ae1f889c3b20a)
|
|
|
|
| |
(cherry picked from commit 6755e9e5c4fdd48452ddaae1094484715ce6d676)
|
|
|
|
| |
(cherry picked from commit 8a4d48c2d1c2ebe8b620b24e839eae16e9b75373)
|
|
|
|
| |
(cherry picked from commit b6cfadc26766efb29394201be501c27301f2bf29)
|
|
|
|
| |
(cherry picked from commit 554a84b16337a75cabd093e79c56850959734467)
|
|
|
|
| |
(cherry picked from commit 8c022b83c59fda46831f657c2118bc9de9147af2)
|
|
|
|
| |
(cherry picked from commit e4bc61e4a3dfd5a4396247eb323070ec8a38fede)
|
|
|
|
|
|
|
|
|
| |
macOS actually uses the alpha channel on windows, so we can get visual
artifacts if we feed it bogus alpha data. This filtering unfortunately
causes some CPU usage, but it's necessary until we can make sure the
framebuffer always contains proper 0xff for alpha.
(cherry picked from commit a88991bdc8154bda8a805755dd82cb71c93b35df)
|
|
|
|
|
|
|
|
| |
We won't always be on the primary monitor, so check which color space
we're actually using right now. For offscreen stuff we assume a standard
sRGB color space.
(cherry picked from commit 1669a2d5a15aa39313cb74eff4f62dfe14d136cd)
|
|
|
|
|
|
|
|
| |
The system expects these to be immutable, so changing the data after
creation only works in some special cases. We need to recreate the
CGImage object each time we've changed something.
(cherry picked from commit 3b347313f1880c0744fd7aa29f45ea010dcfcf42)
|
|
|
|
|
|
| |
It seems to be more efficient.
(cherry picked from commit 2d0dc3abee27c9383ad3ab23e02ecf94fcdd7596)
|
|
|
|
|
|
| |
Some backends don't like empty draw operations, so have an early check.
(cherry picked from commit 0630434292b19898e6bd66e46cc4c6a641efdfe5)
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|\
| |
| |
| | |
https://github.com/michalsrb/tigervnc
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
|
|
|
| |
Everyone else seems to get by with using 0600, so let's do the same.
|
|
|
|
|
| |
It's not enough that we detach from the shared memory, we must also
tell the X server to do so for it to be freed properly.
|
|\ \
| | |
| | |
| | | |
https://github.com/michalsrb/tigervnc
|
| | |
| | |
| | |
| | | |
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.
|
|/ |
|
|
|
|
| |
Should have been included in the previous commit.
|
| |
|
| |
|
|
|
|
| |
It has been out of date for some time.
|
| |
|
| |
|
| |
|
|\ |
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| | |
|