From nobody Sat Oct 25 21:30:35 2025 Delivered-To: importer@patchew.org Received-SPF: pass (zoho.com: domain of gnu.org designates 208.118.235.17 as permitted sender) client-ip=208.118.235.17; envelope-from=qemu-devel-bounces+importer=patchew.org@nongnu.org; helo=lists.gnu.org; Authentication-Results: mx.zohomail.com; spf=pass (zoho.com: domain of gnu.org designates 208.118.235.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org Return-Path: Received: from lists.gnu.org (lists.gnu.org [208.118.235.17]) by mx.zohomail.com with SMTPS id 151629085832061.744587601595754; Thu, 18 Jan 2018 07:54:18 -0800 (PST) Received: from localhost ([::1]:38265 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ecCW4-0003l5-BO for importer@patchew.org; Thu, 18 Jan 2018 10:54:12 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:40714) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ecCV8-0003Kn-Fw for qemu-devel@nongnu.org; Thu, 18 Jan 2018 10:53:15 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ecCV5-0002Xk-73 for qemu-devel@nongnu.org; Thu, 18 Jan 2018 10:53:14 -0500 Received: from mx1.redhat.com ([209.132.183.28]:53684) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1ecCV4-0002WH-Ua for qemu-devel@nongnu.org; Thu, 18 Jan 2018 10:53:11 -0500 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id B4BBE12E51D; Thu, 18 Jan 2018 15:53:09 +0000 (UTC) Received: from t460.redhat.com (unknown [10.33.36.28]) by smtp.corp.redhat.com (Postfix) with ESMTP id 4F1C617CF2; Thu, 18 Jan 2018 15:52:59 +0000 (UTC) From: "Daniel P. Berrange" To: qemu-devel@nongnu.org Date: Thu, 18 Jan 2018 15:52:54 +0000 Message-Id: <20180118155254.17053-1-berrange@redhat.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.38]); Thu, 18 Jan 2018 15:53:09 +0000 (UTC) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 209.132.183.28 Subject: [Qemu-devel] [PATCH] ui: avoid sign extension using client width/height X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Paolo Bonzini , Gerd Hoffmann , Peter Maydell Errors-To: qemu-devel-bounces+importer=patchew.org@nongnu.org Sender: "Qemu-devel" X-ZohoMail: RSF_0 Z_629925259 SPT_0 Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" 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 =3D >>> 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 --- ui/vnc.c | 9 +++++++++ ui/vnc.h | 4 ++-- 2 files changed, 11 insertions(+), 2 deletions(-) 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 =3D=3D pixman_image_get_height(vs->vd->server)) { return; } + + assert(pixman_image_get_width(vs->vd->server) < 65536 && + pixman_image_get_width(vs->vd->server) >=3D 0); + assert(pixman_image_get_height(vs->vd->server) < 65536 && + pixman_image_get_height(vs->vd->server) >=3D 0); vs->client_width =3D pixman_image_get_width(vs->vd->server); vs->client_height =3D 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; } =20 + assert(pixman_image_get_width(vs->vd->server) < 65536 && + pixman_image_get_width(vs->vd->server) >=3D 0); + assert(pixman_image_get_height(vs->vd->server) < 65536 && + pixman_image_get_height(vs->vd->server) >=3D 0); vs->client_width =3D pixman_image_get_width(vs->vd->server); vs->client_height =3D pixman_image_get_height(vs->vd->server); vnc_write_u16(vs, vs->client_width); 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; =20 uint32_t vnc_encoding; --=20 2.14.3