From nobody Tue Nov 26 09:00:07 2024 Delivered-To: importer@patchew.org Authentication-Results: mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org; dmarc=pass(p=none dis=none) header.from=redhat.com ARC-Seal: i=1; a=rsa-sha256; t=1709280682; cv=none; d=zohomail.com; s=zohoarc; b=FZG95KxfolwUXnOxvOce9Mfmsg2fS4nzri6zwer1H8WCcwD+scIr8/oKavSuEsNK8UAD3iAr3XNFst85UCgHEHqbAW2OvvrZ22qzl+L0OpWt6t2is961aW+WKtqVbVkxjmyrmOKTN6bBU3NRNQX1myz29ndcrhw9jocwCfnyGZ0= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1709280682; h=Content-Type:Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:List-Subscribe:List-Post:List-Id:List-Archive:List-Help:List-Unsubscribe:MIME-Version:Message-ID:References:Sender:Subject:Subject:To:To:Message-Id:Reply-To; bh=5R45Lc/B9oh0/zhXjUTXJbEhi/IWIqIJongcvYiTcK8=; b=WV7FgsmnokDjM9xp5GJSz7dUJznEr/Id4Ft2rvmN81tjrguie3wrwYK92aycrMAKUuwcS1k3aqBdLNbiH3f3sysSvq8OtSfKlL14xtEGFr9ZVr+1lc+D92/GmKN3WbfiLgVZNawQAGYQt3uQXSsu2MpOF41aErt+GSISaXGQZEY= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org; dmarc=pass header.from= (p=none dis=none) Return-Path: Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) by mx.zohomail.com with SMTPS id 1709280682208887.6985290510194; Fri, 1 Mar 2024 00:11:22 -0800 (PST) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rfxyC-0003KF-9q; Fri, 01 Mar 2024 03:10:16 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rfxyA-0003J3-5E for qemu-devel@nongnu.org; Fri, 01 Mar 2024 03:10:14 -0500 Received: from us-smtp-delivery-124.mimecast.com ([170.10.133.124]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rfxy8-0006wl-5R for qemu-devel@nongnu.org; Fri, 01 Mar 2024 03:10:13 -0500 Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-224-VLf0SUjdPQ-_BdHSaiv-EA-1; Fri, 01 Mar 2024 03:10:08 -0500 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.rdu2.redhat.com [10.11.54.4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 31A2A868034; Fri, 1 Mar 2024 08:10:05 +0000 (UTC) Received: from thuth-p1g4.redhat.com (unknown [10.39.193.125]) by smtp.corp.redhat.com (Postfix) with ESMTP id 672E4201F362; Fri, 1 Mar 2024 08:10:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1709280611; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=5R45Lc/B9oh0/zhXjUTXJbEhi/IWIqIJongcvYiTcK8=; b=c5A4dwpCT9BTwdE/3FpVwJdtE4j06uS8cZcJbWg6KyiBtytVLep3P+AH1ku6m4Qgklb6if 8Ac55BOig4RAfseTcU64TzwnDvoAJN08HiiznAJly6AnYyBBpcGIncVfFlQ1Y1EY3+BybQ eOF4WIBmD2SJUseFrcR5W9LGWKFg6IQ= X-MC-Unique: VLf0SUjdPQ-_BdHSaiv-EA-1 From: Thomas Huth To: qemu-devel@nongnu.org Cc: Peter Maydell , qemu-stable@nongnu.org, =?UTF-8?q?Daniel=20P=2E=20Berrang=C3=A9?= , Antoine Damhet , =?UTF-8?q?Marc-Andr=C3=A9=20Lureau?= Subject: [PULL 6/6] chardev/char-socket: Fix TLS io channels sending too much data to the backend Date: Fri, 1 Mar 2024 09:09:53 +0100 Message-ID: <20240301080953.66448-7-thuth@redhat.com> In-Reply-To: <20240301080953.66448-1-thuth@redhat.com> References: <20240301080953.66448-1-thuth@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.4 Received-SPF: pass (zohomail.com: domain of gnu.org designates 209.51.188.17 as permitted sender) client-ip=209.51.188.17; envelope-from=qemu-devel-bounces+importer=patchew.org@nongnu.org; helo=lists.gnu.org; Received-SPF: pass client-ip=170.10.133.124; envelope-from=thuth@redhat.com; helo=us-smtp-delivery-124.mimecast.com X-Spam_score_int: -21 X-Spam_score: -2.2 X-Spam_bar: -- X-Spam_report: (-2.2 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.096, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=unavailable autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+importer=patchew.org@nongnu.org Sender: qemu-devel-bounces+importer=patchew.org@nongnu.org X-ZohoMail-DKIM: pass (identity @redhat.com) X-ZM-MESSAGEID: 1709280682409100005 Commit ffda5db65a ("io/channel-tls: fix handling of bigger read buffers") changed the behavior of the TLS io channels to schedule a second reading attempt if there is still incoming data pending. This caused a regression with backends like the sclpconsole that check in their read function that the sender does not try to write more bytes to it than the device can currently handle. The problem can be reproduced like this: 1) In one terminal, do this: mkdir qemu-pki cd qemu-pki openssl genrsa 2048 > ca-key.pem openssl req -new -x509 -nodes -days 365000 -key ca-key.pem -out ca-cert.p= em # enter some dummy value for the cert openssl genrsa 2048 > server-key.pem openssl req -new -x509 -nodes -days 365000 -key server-key.pem \ -out server-cert.pem # enter some other dummy values for the cert gnutls-serv --echo --x509cafile ca-cert.pem --x509keyfile server-key.pem \ --x509certfile server-cert.pem -p 8338 2) In another terminal, do this: wget https://download.fedoraproject.org/pub/fedora-secondary/releases/39/= Cloud/s390x/images/Fedora-Cloud-Base-39-1.5.s390x.qcow2 qemu-system-s390x -nographic -nodefaults \ -hda Fedora-Cloud-Base-39-1.5.s390x.qcow2 \ -object tls-creds-x509,id=3Dtls0,endpoint=3Dclient,verify-peer=3Dfalse,= dir=3D$PWD/qemu-pki \ -chardev socket,id=3Dtls_chardev,host=3Dlocalhost,port=3D8338,tls-creds= =3Dtls0 \ -device sclpconsole,chardev=3Dtls_chardev,id=3Dtls_serial QEMU then aborts after a second or two with: qemu-system-s390x: ../hw/char/sclpconsole.c:73: chr_read: Assertion `size <=3D SIZE_BUFFER_VT220 - scon->iov_data_len' failed. Aborted (core dumped) It looks like the second read does not trigger the chr_can_read() function to be called before the second read, which should normally always be done before sending bytes to a character device to see how much it can handle, so the s->max_size in tcp_chr_read() still contains the old value from the previous read. Let's make sure that we use the up-to-date value by calling tcp_chr_read_poll() again here. Cc: qemu-stable@nongnu.org Fixes: ffda5db65a ("io/channel-tls: fix handling of bigger read buffers") Buglink: https://issues.redhat.com/browse/RHEL-24614 Reviewed-by: "Daniel P. Berrang=C3=A9" Message-ID: <20240229104339.42574-1-thuth@redhat.com> Reviewed-by: Antoine Damhet Tested-by: Antoine Damhet Reviewed-by: Marc-Andr=C3=A9 Lureau Signed-off-by: Thomas Huth --- chardev/char-socket.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/chardev/char-socket.c b/chardev/char-socket.c index 67e3334423..8a0406cc1e 100644 --- a/chardev/char-socket.c +++ b/chardev/char-socket.c @@ -496,9 +496,9 @@ static gboolean tcp_chr_read(QIOChannel *chan, GIOCondi= tion cond, void *opaque) s->max_size <=3D 0) { return TRUE; } - len =3D sizeof(buf); - if (len > s->max_size) { - len =3D s->max_size; + len =3D tcp_chr_read_poll(opaque); + if (len > sizeof(buf)) { + len =3D sizeof(buf); } size =3D tcp_chr_recv(chr, (void *)buf, len); if (size =3D=3D 0 || (size =3D=3D -1 && errno !=3D EAGAIN)) { --=20 2.44.0