All of lore.kernel.org
 help / color / mirror / Atom feed
From: Gerd Hoffmann <kraxel@redhat.com>
To: qemu-devel@nongnu.org
Cc: "Daniel P. Berrange" <berrange@redhat.com>,
	Gerd Hoffmann <kraxel@redhat.com>
Subject: [Qemu-devel] [PULL 1/8] ui: avoid sign extension using client width/height
Date: Thu, 25 Jan 2018 15:32:11 +0100	[thread overview]
Message-ID: <20180125143218.29528-2-kraxel@redhat.com> (raw)
In-Reply-To: <20180125143218.29528-1-kraxel@redhat.com>

From: "Daniel P. Berrange" <berrange@redhat.com>

Pixman returns a signed int for the image width/height, but the VNC
protocol only permits a unsigned int16. Effective framebuffer size
is determined by the guest, limited by the video RAM size, so the
dimensions are unlikely to exceed the range of an unsigned int16,
but this is not currently validated.

With the current use of 'int' for client width/height, the calculation
of offsets in vnc_update_throttle_offset() suffers from integer size
promotion and sign extension, causing coverity warnings

*** CID 1385147:  Integer handling issues  (SIGN_EXTENSION)
/ui/vnc.c: 979 in vnc_update_throttle_offset()
973      * than that the client would already suffering awful audio
974      * glitches, so dropping samples is no worse really).
975      */
976     static void vnc_update_throttle_offset(VncState *vs)
977     {
978         size_t offset =
>>>     CID 1385147:  Integer handling issues  (SIGN_EXTENSION)
>>>     Suspicious implicit sign extension:
    "vs->client_pf.bytes_per_pixel" with type "unsigned char" (8 bits,
    unsigned) is promoted in "vs->client_width * vs->client_height *
    vs->client_pf.bytes_per_pixel" to type "int" (32 bits, signed), then
    sign-extended to type "unsigned long" (64 bits, unsigned).  If
    "vs->client_width * vs->client_height * vs->client_pf.bytes_per_pixel"
    is greater than 0x7FFFFFFF, the upper bits of the result will all be 1.
979             vs->client_width * vs->client_height * vs->client_pf.bytes_per_pixel;

Change client_width / client_height to be a size_t to avoid sign
extension and integer promotion. Then validate that dimensions are in
range wrt the RFB protocol u16 limits.

Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Message-id: 20180118155254.17053-1-berrange@redhat.com
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
---
 ui/vnc.h | 4 ++--
 ui/vnc.c | 9 +++++++++
 2 files changed, 11 insertions(+), 2 deletions(-)

diff --git a/ui/vnc.h b/ui/vnc.h
index 0c33a5f7fe..bbda0540a7 100644
--- a/ui/vnc.h
+++ b/ui/vnc.h
@@ -278,8 +278,8 @@ struct VncState
     int last_x;
     int last_y;
     uint32_t last_bmask;
-    int client_width;
-    int client_height;
+    size_t client_width; /* limited to u16 by RFB proto */
+    size_t client_height; /* limited to u16 by RFB proto */
     VncShareMode share_mode;
 
     uint32_t vnc_encoding;
diff --git a/ui/vnc.c b/ui/vnc.c
index 665a143578..33b087221f 100644
--- a/ui/vnc.c
+++ b/ui/vnc.c
@@ -672,6 +672,11 @@ static void vnc_desktop_resize(VncState *vs)
         vs->client_height == pixman_image_get_height(vs->vd->server)) {
         return;
     }
+
+    assert(pixman_image_get_width(vs->vd->server) < 65536 &&
+           pixman_image_get_width(vs->vd->server) >= 0);
+    assert(pixman_image_get_height(vs->vd->server) < 65536 &&
+           pixman_image_get_height(vs->vd->server) >= 0);
     vs->client_width = pixman_image_get_width(vs->vd->server);
     vs->client_height = pixman_image_get_height(vs->vd->server);
     vnc_lock_output(vs);
@@ -2490,6 +2495,10 @@ static int protocol_client_init(VncState *vs, uint8_t *data, size_t len)
         return 0;
     }
 
+    assert(pixman_image_get_width(vs->vd->server) < 65536 &&
+           pixman_image_get_width(vs->vd->server) >= 0);
+    assert(pixman_image_get_height(vs->vd->server) < 65536 &&
+           pixman_image_get_height(vs->vd->server) >= 0);
     vs->client_width = pixman_image_get_width(vs->vd->server);
     vs->client_height = pixman_image_get_height(vs->vd->server);
     vnc_write_u16(vs, vs->client_width);
-- 
2.9.3

  reply	other threads:[~2018-01-25 14:32 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-25 14:32 [Qemu-devel] [PULL 0/8] Ui 20180125 patches Gerd Hoffmann
2018-01-25 14:32 ` Gerd Hoffmann [this message]
2018-01-25 14:32 ` [Qemu-devel] [PULL 2/8] ui: convert the SDL2 frontend to keycodemapdb Gerd Hoffmann
2018-02-01 17:28   ` Paolo Bonzini
2018-02-01 17:35     ` Daniel P. Berrangé
2018-02-01 17:37       ` Paolo Bonzini
2018-02-01 17:54         ` Daniel P. Berrangé
2018-02-01 18:10           ` Paolo Bonzini
2018-02-01 18:13             ` Daniel P. Berrangé
2018-01-25 14:32 ` [Qemu-devel] [PULL 3/8] ui: convert GTK and SDL1 frontends " Gerd Hoffmann
2018-01-25 14:32 ` [Qemu-devel] [PULL 4/8] ui: add fix for GTK Pause key handling on Win32 Gerd Hoffmann
2018-01-25 14:32 ` [Qemu-devel] [PULL 5/8] ui: ignore hardware keycode 255 on win32 Gerd Hoffmann
2018-01-25 14:32 ` [Qemu-devel] [PULL 6/8] ui: deprecate use of SDL 1.2 in favour of 2.0 series Gerd Hoffmann
2018-01-25 14:32 ` [Qemu-devel] [PULL 7/8] sdl: use ctrl-alt-g as grab hotkey Gerd Hoffmann
2018-01-25 14:32 ` [Qemu-devel] [PULL 8/8] sdl: reorganize -no-frame support Gerd Hoffmann
2018-01-26 10:08 ` [Qemu-devel] [PULL 0/8] Ui 20180125 patches Peter Maydell

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180125143218.29528-2-kraxel@redhat.com \
    --to=kraxel@redhat.com \
    --cc=berrange@redhat.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.