Details
-
Bug
-
Resolution: Done
-
P1: Critical
-
4.5.2
-
None
-
Embedded Linux , Kernel 2.6, GNU compiler 3.4, VNC-Server
-
71b840ef81a91605beecbb3cccfa0f85c3289e19
Description
The bug occurs when QVNCServer::readClient() receives a message of type ClientCutText, but the second message of the same type, containing the rest of the text, was not received yet.
In this case QVNCServer::readClient() calls QVNCServer::clientCutText(). The first thing, clientCutText() does, is reading the length of the client cut text (QRfbClientCutText). After this the method checks via client->bytesAvailable() if there are more bytes to read. In this case the result is "no". So QVNCServer::clientCutText() returns to QVNCServer::readClient(), which runs in a loop. Therefore QVNCServer::clientCutText() is called again and there is the bug. clientCutText() reads the length again, even though it has already done this before. So the data it gets is not really the length but rather some other data, for example a part of a string.
The next thing QVNCServer::clientCutText() does is allocating memory with the erroneous length, which can lead to a crash.
So, before reading the length of the text, QVNCServer::clientCutText() should check, if we already have done that:
void QVNCServer::clientCutText() { QRfbClientCutText ev; if (0 == cutTextPending) { if (ev.read(client)) { cutTextPending = ev.length; if (!cutTextPending) handleMsg = false; } } // .. some more code }