From nobody Fri Dec 12 12:53:43 2025 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of lists.libvirt.org designates 8.43.85.245 as permitted sender) client-ip=8.43.85.245; envelope-from=devel-bounces@lists.libvirt.org; helo=lists.libvirt.org; Authentication-Results: mx.zohomail.com; dkim=fail; spf=pass (zohomail.com: domain of lists.libvirt.org designates 8.43.85.245 as permitted sender) smtp.mailfrom=devel-bounces@lists.libvirt.org; dmarc=pass(p=reject dis=none) header.from=lists.libvirt.org ARC-Seal: i=1; a=rsa-sha256; t=1763983258; cv=none; d=zohomail.com; s=zohoarc; b=fphVUOLRUJc2s6ylbF3CO/Z30chR6xPDS4Svbcdo1mwV9psGAliRHoRiqIgUfPVVJoqkRrf2q1Cdnfz/00I9eBNSsGCCZPw+EqkMW5ll2t1yR2xo+h1w2f6ivaR3anLqjeHB29CfEoiltnQql05cYLXsd21Nx1vNtEEhZJume6Q= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1763983258; h=Content-Type:Content-Transfer-Encoding:Date:Date:From:From:List-Subscribe:List-Post:List-Owner:List-Id:List-Archive:List-Help:List-Unsubscribe:MIME-Version:Message-ID:Reply-To:Reply-To:Subject:Subject:To:To:Message-Id:Cc; bh=SXK/9Mg1HxFs4tEQhakCHXXPhYFQNU+lZgHTpK7fwZQ=; b=O9hTaZCOA9su0EDvZ8/maZQGQU+0zZLw8brszYTHwAIstL8nsjYT8DNI0Nn24OLDdp8A5WklM0lq3RddIRBrAdXlRgOqgvxpXTBUlnDfvMwx3GV4aQNpd3Zdf0pF8V6WxNPa7n79pJl7jJNAvqtanjZInT47M1UYOQEzQ/wNZVY= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=fail; spf=pass (zohomail.com: domain of lists.libvirt.org designates 8.43.85.245 as permitted sender) smtp.mailfrom=devel-bounces@lists.libvirt.org; dmarc=pass header.from= (p=reject dis=none) Return-Path: Received: from lists.libvirt.org (lists.libvirt.org [8.43.85.245]) by mx.zohomail.com with SMTPS id 1763983258672309.6589535282128; Mon, 24 Nov 2025 03:20:58 -0800 (PST) Received: by lists.libvirt.org (Postfix, from userid 993) id BB82D43E6E; Mon, 24 Nov 2025 06:20:57 -0500 (EST) Received: from [172.19.199.65] (lists.libvirt.org [8.43.85.245]) by lists.libvirt.org (Postfix) with ESMTP id EEB22443B9; Mon, 24 Nov 2025 06:20:04 -0500 (EST) Received: by lists.libvirt.org (Postfix, from userid 993) id 9752843E66; Mon, 24 Nov 2025 06:19:58 -0500 (EST) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (3072 bits) server-digest SHA256) (No client certificate requested) by lists.libvirt.org (Postfix) with ESMTPS id 88CE143E37 for ; Mon, 24 Nov 2025 06:19:56 -0500 (EST) Received: from mx-prod-mc-08.mail-002.prod.us-west-2.aws.redhat.com (ec2-35-165-154-97.us-west-2.compute.amazonaws.com [35.165.154.97]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-683-4JfcgzIGPc6H_b588vSAzw-1; Mon, 24 Nov 2025 06:19:51 -0500 Received: from mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.111]) (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 mx-prod-mc-08.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 2F18B180034A for ; Mon, 24 Nov 2025 11:19:51 +0000 (UTC) Received: from toolbx.redhat.com (unknown [10.42.28.58]) by mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id 5660B180057F; Mon, 24 Nov 2025 11:19:50 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-26) on lists.libvirt.org X-Spam-Level: X-Spam-Status: No, score=-5.0 required=5.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED,RCVD_IN_VALIDITY_RPBL_BLOCKED, RCVD_IN_VALIDITY_SAFE_BLOCKED,SPF_PASS autolearn=unavailable autolearn_force=no version=4.0.1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1763983196; 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; bh=SXK/9Mg1HxFs4tEQhakCHXXPhYFQNU+lZgHTpK7fwZQ=; b=V0TcvbBmEnrDln05ZwQjJvT4FmfYvSPHVOB0ss1NBYY6wX0K2PUOvhdkPUpS1R8ST5Gs+m MGxJtdsRCmbNd4CZMaXKS8UE+RIAaoG9K01x+9dOnwL8Wt3O7ZZxVkQLwvU729+Wib7HrB 0v7/PGxF50H6JU9mC0E6aMaL9q9ZGgc= X-MC-Unique: 4JfcgzIGPc6H_b588vSAzw-1 X-Mimecast-MFC-AGG-ID: 4JfcgzIGPc6H_b588vSAzw_1763983191 To: devel@lists.libvirt.org Subject: [PATCH] src: cap the data size in stream I/O functions Date: Mon, 24 Nov 2025 11:19:48 +0000 Message-ID: <20251124111948.435436-1-berrange@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.111 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: RYDpyt-SaxP40PP5pQY-8ooNwube0Q6Urac1uBI1OsI_1763983191 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-ID-Hash: ICGTFVRXSEF5NS7QD3PDLJCZ7CPKPLH4 X-Message-ID-Hash: ICGTFVRXSEF5NS7QD3PDLJCZ7CPKPLH4 X-MailFrom: berrange@redhat.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; loop; banned-address; header-match-devel.lists.libvirt.org-0; emergency; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header X-Mailman-Version: 3.3.10 Precedence: list List-Id: Development discussions about the libvirt library & tools Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: From: =?utf-8?q?Daniel_P=2E_Berrang=C3=A9_via_Devel?= Reply-To: =?UTF-8?q?Daniel=20P=2E=20Berrang=C3=A9?= X-ZohoMail-DKIM: fail (Header signature does not verify) X-ZM-MESSAGEID: 1763983260372019200 From: Daniel P. Berrang=C3=A9 The main stream I/O functions have a design flaw in that they accept 'size_t' as the input data length, while intending to return the amount actually processed in an 'int'. Fortunately all functions explicitly document that less data may be processed than requested, and with the remote driver data cap we will never get anywhere near exceeding an 'int' even on 32-bit. For sanity, however, lets explicitly cap the data size in the public API to fix the design flaw. Signed-off-by: Daniel P. Berrang=C3=A9 Reviewed-by: Peter Krempa --- src/libvirt-stream.c | 27 +++++++++++++++++++++++++++ 1 file changed, 27 insertions(+) diff --git a/src/libvirt-stream.c b/src/libvirt-stream.c index ca4d90140e..61c700c19e 100644 --- a/src/libvirt-stream.c +++ b/src/libvirt-stream.c @@ -182,6 +182,15 @@ virStreamSend(virStreamPtr stream, virCheckStreamReturn(stream, -1); virCheckNonNullArgGoto(data, error); =20 + /* + * We accept size_t which could be 2^64-1, but we need to return + * bytes processed in a signed int, so must cap the request to + * fit in a 'signed int' on a 32-bit platform. + */ + if (nbytes > G_MAXINT32) { + nbytes =3D G_MAXINT32; + } + if (stream->driver && stream->driver->streamSend) { int ret; @@ -279,6 +288,15 @@ virStreamRecv(virStreamPtr stream, virCheckStreamReturn(stream, -1); virCheckNonNullArgGoto(data, error); =20 + /* + * We accept size_t which could be 2^64-1, but we need to return + * bytes processed in a signed int, so must cap the request to + * fit in a 'signed int' on a 32-bit platform. + */ + if (nbytes > G_MAXINT32) { + nbytes =3D G_MAXINT32; + } + if (stream->driver && stream->driver->streamRecv) { int ret; @@ -370,6 +388,15 @@ virStreamRecvFlags(virStreamPtr stream, virCheckStreamReturn(stream, -1); virCheckNonNullArgGoto(data, error); =20 + /* + * We accept size_t which could be 2^64-1, but we need to return + * bytes processed in a signed int, so must cap the request to + * fit in a 'signed int' on a 32-bit platform. + */ + if (nbytes > G_MAXINT32) { + nbytes =3D G_MAXINT32; + } + if (stream->driver && stream->driver->streamRecvFlags) { int ret; --=20 2.51.1