[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-devel] [PATCH] Fix infinite loop caused by mishandling of type-6 V

From: Marc Bevand
Subject: [Qemu-devel] [PATCH] Fix infinite loop caused by mishandling of type-6 VNC client messages
Date: Mon, 27 Aug 2007 23:00:57 +0000 (UTC)
User-agent: Loom/3.14 (http://gmane.org/)

Hi, I have been using QEMU's VNC support quite extensively since 0.8.1
came out, and every once in a while QEMU froze on me while interacting
with a guest OS through a VNC client. I recently spent some time
tracking down this bug in QEMU 0.9.0 and I found and fixed it in vnc.c
(see patch below).

In protocol_client_msg(), type-6 messages ("client cut text") are not
handled properly. From time to time my VNC client (xvncviewer version
3.3.7-8ubuntu2_amd64.deb, from Ubuntu 6.06.1) appears to send type-6
messages with an empty text string:

  06            message-type
  xx xx xx      padding
  00 00 00 00   length
  -             (empty text string)

This causes protocol_client_msg() to enter this if-condition:

  if (len == 8)
    return 8 + read_u32(data, 4);

Which returns 8 (8 + 0), meaning that 8 more bytes are expected (it
doesn't realize that the lenght field is 0.) This causes QEMU to enter
an infinite loop: protocol_client_msg keeps getting called again and
again, making the guest OS appear frozen.

The bug seems to stil exist in CVS HEAD, I made a patch against
qemu-snapshot-2007-08-27_05, please apply it.


--- qemu-snap-2007-08-27_05/vnc.c.orig      2007-08-24 18:39:57.000000000 -0700
+++ qemu-snap-2007-08-27_05/vnc.c   2007-08-27 15:25:57.379836750 -0700
@@ -1196,7 +1196,11 @@
            return 8;

        if (len == 8)
-           return 8 + read_u32(data, 4);
+          {
+           uint32_t dlen = read_u32(data, 4);
+           if (dlen > 0)
+              return 8 + dlen;
+          }

        client_cut_text(vs, read_u32(data, 4), data + 8);

reply via email to

[Prev in Thread] Current Thread [Next in Thread]