From nobody Tue Feb 10 17:08:11 2026 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 1515762253737631.7323362532751; Fri, 12 Jan 2018 05:04:13 -0800 (PST) Received: from localhost ([::1]:39930 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eZz0F-0007bl-Vb for importer@patchew.org; Fri, 12 Jan 2018 08:04:12 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:48323) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eZyvG-0003NR-Mx for qemu-devel@nongnu.org; Fri, 12 Jan 2018 07:59:08 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eZyvF-0002pM-JR for qemu-devel@nongnu.org; Fri, 12 Jan 2018 07:59:02 -0500 Received: from mx1.redhat.com ([209.132.183.28]:54194) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1eZyvF-0002oJ-DQ for qemu-devel@nongnu.org; Fri, 12 Jan 2018 07:59:01 -0500 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 7D6F6C0272F6 for ; Fri, 12 Jan 2018 12:59:00 +0000 (UTC) Received: from sirius.home.kraxel.org (ovpn-116-239.ams2.redhat.com [10.36.116.239]) by smtp.corp.redhat.com (Postfix) with ESMTP id 633A584FF; Fri, 12 Jan 2018 12:58:56 +0000 (UTC) Received: by sirius.home.kraxel.org (Postfix, from userid 1000) id 69C21409CD; Fri, 12 Jan 2018 13:58:54 +0100 (CET) From: Gerd Hoffmann To: qemu-devel@nongnu.org Date: Fri, 12 Jan 2018 13:58:46 +0100 Message-Id: <20180112125854.18261-7-kraxel@redhat.com> In-Reply-To: <20180112125854.18261-1-kraxel@redhat.com> References: <20180112125854.18261-1-kraxel@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.31]); Fri, 12 Jan 2018 12:59:00 +0000 (UTC) Content-Transfer-Encoding: quoted-printable 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] [PULL 06/14] ui: track how much decoded data we consumed when doing SASL encoding 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: Gerd Hoffmann Errors-To: qemu-devel-bounces+importer=patchew.org@nongnu.org Sender: "Qemu-devel" X-ZohoMail: RSF_0 Z_629925259 SPT_0 Content-Type: text/plain; charset="utf-8" From: "Daniel P. Berrange" When we encode data for writing with SASL, we encode the entire pending out= put buffer. The subsequent write, however, may not be able to send the full enc= oded data in one go though, particularly with a slow network. So we delay settin= g the output buffer offset back to zero until all the SASL encoded data is sent. Between encoding the data and completing sending of the SASL encoded data, however, more data might have been placed on the pending output buffer. So = it is not valid to set offset back to zero. Instead we must keep track of how = much data we consumed during encoding and subtract only that amount. With the current bug we would be throwing away some pending data without ha= ving sent it at all. By sheer luck this did not previously cause any serious pro= blem because appending data to the send buffer is always an atomic action, so we only ever throw away complete RFB protocol messages. In the case of frame b= uffer updates we'd catch up fairly quickly, so no obvious problem was visible. Signed-off-by: Daniel P. Berrange Reviewed-by: Darren Kenny Reviewed-by: Marc-Andr=C3=A9 Lureau Message-id: 20171218191228.31018-6-berrange@redhat.com Signed-off-by: Gerd Hoffmann --- ui/vnc-auth-sasl.h | 1 + ui/vnc-auth-sasl.c | 3 ++- 2 files changed, 3 insertions(+), 1 deletion(-) diff --git a/ui/vnc-auth-sasl.h b/ui/vnc-auth-sasl.h index cb42745a6b..b9d8de1c10 100644 --- a/ui/vnc-auth-sasl.h +++ b/ui/vnc-auth-sasl.h @@ -53,6 +53,7 @@ struct VncStateSASL { */ const uint8_t *encoded; unsigned int encodedLength; + unsigned int encodedRawLength; unsigned int encodedOffset; char *username; char *mechlist; diff --git a/ui/vnc-auth-sasl.c b/ui/vnc-auth-sasl.c index 23f28280e7..761493b9b2 100644 --- a/ui/vnc-auth-sasl.c +++ b/ui/vnc-auth-sasl.c @@ -67,6 +67,7 @@ long vnc_client_write_sasl(VncState *vs) if (err !=3D SASL_OK) return vnc_client_io_error(vs, -1, NULL); =20 + vs->sasl.encodedRawLength =3D vs->output.offset; vs->sasl.encodedOffset =3D 0; } =20 @@ -78,7 +79,7 @@ long vnc_client_write_sasl(VncState *vs) =20 vs->sasl.encodedOffset +=3D ret; if (vs->sasl.encodedOffset =3D=3D vs->sasl.encodedLength) { - vs->output.offset =3D 0; + vs->output.offset -=3D vs->sasl.encodedRawLength; vs->sasl.encoded =3D NULL; vs->sasl.encodedOffset =3D vs->sasl.encodedLength =3D 0; } --=20 2.9.3