From nobody Thu May 16 23:25:12 2024 Delivered-To: importer@patchew.org Received-SPF: none (zohomail.com: 8.43.85.245 is neither permitted nor denied by domain of lists.libvirt.org) client-ip=8.43.85.245; envelope-from=devel-bounces@lists.libvirt.org; helo=lists.libvirt.org; Authentication-Results: mx.zohomail.com; spf=none (zohomail.com: 8.43.85.245 is neither permitted nor denied by domain of lists.libvirt.org) smtp.mailfrom=devel-bounces@lists.libvirt.org; dmarc=fail(p=none dis=none) header.from=redhat.com Return-Path: Received: from lists.libvirt.org (lists.libvirt.org [8.43.85.245]) by mx.zohomail.com with SMTPS id 1700834340158335.3540071205481; Fri, 24 Nov 2023 05:59:00 -0800 (PST) Received: by lists.libvirt.org (Postfix, from userid 996) id 4B6B11910; Fri, 24 Nov 2023 08:58:58 -0500 (EST) Received: from lists.libvirt.org (localhost [IPv6:::1]) by lists.libvirt.org (Postfix) with ESMTP id DDF5317E2; Fri, 24 Nov 2023 08:57:52 -0500 (EST) Received: by lists.libvirt.org (Postfix, from userid 996) id 807ED180C; Fri, 24 Nov 2023 08:57:50 -0500 (EST) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.libvirt.org (Postfix) with ESMTPS id AD5DD1805 for ; Fri, 24 Nov 2023 08:57:49 -0500 (EST) Received: from mimecast-mx02.redhat.com (mx-ext.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-297-if6pK7_3NBSivxYaLvmJkQ-1; Fri, 24 Nov 2023 08:57:48 -0500 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.rdu2.redhat.com [10.11.54.5]) (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 885A729AA3A5 for ; Fri, 24 Nov 2023 13:57:47 +0000 (UTC) Received: from maggie.brq.redhat.com (unknown [10.43.3.102]) by smtp.corp.redhat.com (Postfix) with ESMTP id 340EA5028 for ; Fri, 24 Nov 2023 13:57:47 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on lists.libvirt.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.4 X-MC-Unique: if6pK7_3NBSivxYaLvmJkQ-1 From: Michal Privoznik To: devel@lists.libvirt.org Subject: [PATCH] virnuma: Avoid integer overflow in virNumaGetPages() Date: Fri, 24 Nov 2023 14:57:44 +0100 Message-ID: MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.5 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Message-ID-Hash: IURYZ2TFKXSL3TVDFPK7DYQMRQQ57OP3 X-Message-ID-Hash: IURYZ2TFKXSL3TVDFPK7DYQMRQQ57OP3 X-MailFrom: mprivozn@redhat.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-config-1; header-match-config-2; header-match-config-3; header-match-devel.lists.libvirt.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; suspicious-header X-Mailman-Version: 3.2.2 Precedence: list List-Id: Development discussions about the libvirt library & tools Archived-At: List-Archive: List-Help: List-Post: List-Subscribe: List-Unsubscribe: Content-Type: text/plain; charset="utf-8"; x-default="true" Content-Transfer-Encoding: quoted-printable X-ZM-MESSAGEID: 1700834341036100001 On systems with humongous pages (16GiB) and 32bit int it's easy to hit integer overflow in virNumaGetPages(). What happens is, inside of virNumaGetPages() as we process hugepages for given NUMA node (e.g. in order to produce capabilities XML), we keep a sum of sizes of pools in an ULL variable (huge_page_sum). In each iteration, the variable is incremented by 1024 * page_size * page_avail. Now, page_size is just an uint, so we have: ULL +=3D U * U * ULL; and because of associativity, U * U is computed first and since we have two operands of the same type, no type expansion happens. But this means, for humongous pages (like 16GiB) the multiplication overflows. Therefore, move the multiplication out of the loop. This helps in two ways: 1) now we have ULL +=3D U * ULL; which expands the uint in multiplication, 2) it saves couple of CPU cycles. Resolves: https://issues.redhat.com/browse/RHEL-16749 Signed-off-by: Michal Privoznik Reviewed-by: J=C3=A1n Tomko --- src/util/virnuma.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/src/util/virnuma.c b/src/util/virnuma.c index 5053a70c61..9393c20875 100644 --- a/src/util/virnuma.c +++ b/src/util/virnuma.c @@ -787,9 +787,7 @@ virNumaGetPages(int node, tmp_free[ntmp] =3D page_free; ntmp++; =20 - /* page_size is in kibibytes while we want huge_page_sum - * in just bytes. */ - huge_page_sum +=3D 1024 * page_size * page_avail; + huge_page_sum +=3D page_size * page_avail; } =20 if (direrr < 0) @@ -800,6 +798,9 @@ virNumaGetPages(int node, VIR_REALLOC_N(tmp_avail, ntmp + 1); VIR_REALLOC_N(tmp_free, ntmp + 1); =20 + /* page_size is in kibibytes while we want huge_page_sum in just bytes= . */ + huge_page_sum *=3D 1024; + if (virNumaGetPageInfo(node, system_page_size, huge_page_sum, &tmp_avail[ntmp], &tmp_free[ntmp]) < 0) return -1; --=20 2.41.0 _______________________________________________ Devel mailing list -- devel@lists.libvirt.org To unsubscribe send an email to devel-leave@lists.libvirt.org