From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id 2D2813858D1E for ; Tue, 14 Feb 2023 06:00:02 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 2D2813858D1E Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1676354401; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to; bh=4bauA9s+LBkic7HXHsWExvPw6F5YXA8kexuJrduumio=; b=b3zKnHrMG+pgmu94UVVt3Qv7n9SFKME0jEYTOQ0HpELq1U3weMIRQWbAGARM4jxr2r3yev 47ji2xVi/hP8p53903uXWyPJmNFIMibOz/NU56M4c6RMvqhDXPPk1elRLTX9FIg3ac1C73 Fr2k6kBkMH4h5s0mkhIVob/+rVPkVYo= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-446-_0ub1rPmPc6FiDOTOsecAA-1; Tue, 14 Feb 2023 00:59:59 -0500 X-MC-Unique: _0ub1rPmPc6FiDOTOsecAA-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.rdu2.redhat.com [10.11.54.8]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 6BDBC85A5A3 for ; Tue, 14 Feb 2023 05:59:59 +0000 (UTC) Received: from greed.delorie.com (unknown [10.22.8.52]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 571D2C16022 for ; Tue, 14 Feb 2023 05:59:59 +0000 (UTC) Received: from greed.delorie.com.redhat.com (localhost [127.0.0.1]) by greed.delorie.com (8.15.2/8.15.2) with ESMTP id 31E5xwuw590717 for ; Tue, 14 Feb 2023 00:59:58 -0500 From: DJ Delorie To: libc-alpha@sourceware.org Subject: [PATCH v2] gmon: Fix allocated buffer overflow (bug 2944) In-Reply-To: Date: Tue, 14 Feb 2023 00:59:58 -0500 Message-ID: MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.1 on 10.11.54.8 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-9.0 required=5.0 tests=BAYES_00,BODY_8BITS,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,GIT_PATCH_0,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Not getting any feedback from my review-with-questions, I'm posting a patch that assumes I'm right about the change I thought Leonid's patch needed. Fight! ;-) >From f7fddb025720d4e318fe5425f5a3235e73a13282 Mon Sep 17 00:00:00 2001 From: "=D0=9B=D0=B5=D0=BE=D0=BD=D0=B8=D0=B4 =D0=AE=D1=80=D1=8C=D0=B5=D0=B2 = (Leonid Yuriev)" Date: Sat, 4 Feb 2023 14:41:38 +0300 Subject: gmon: Fix allocated buffer overflow (bug 2944) MIME-Version: 1.0 Content-Type: text/plain; charset=3DUTF-8 Content-Transfer-Encoding: 8bit The `__monstartup()` allocates a buffer used to store all the data accumulated by the monitor. The size of this buffer depends on the size of the internal structures used and the address range for which the monitor is activated, as well as on the maximum density of call instuctions and/or callable functions that could be potentially on a segment of executable code. In particular a hash table of arcs is placed at the end of this buffer. The size of this hash table is calculated in bytes as p->fromssize =3D p->textsize / HASHFRACTION; but actually should be p->fromssize =3D ROUNDUP(p->textsize / HASHFRACTION, sizeof(*p->froms)); This results in writing beyond the end of the allocated buffer when an added arc corresponds to a call near from the end of the monitored address range, since `_mcount()` check the incoming caller address for monitored range but not the intermediate result hash-like index that uses to write into the table. It should be noted that when the results are output to `gmon.out`, the table is read to the last element calculated from the allocated size in bytes, so the arcs stored outside the buffer boundary did not fall into `gprof` for analysis. Thus this "feature" help me to found this bug during working with https://sourceware.org/bugzilla/show_bug.cgi?id=3D29438 Just in case, I will explicitly note that the problem breaks the `make test t=3Dgmon/tst-gmon-dso` added for Bug 29438. There, the arc of the `f3()` call disappears from the output, since in the DSO case, the call to `f3` is located close to the end of the monitored range. Signed-off-by: =D0=9B=D0=B5=D0=BE=D0=BD=D0=B8=D0=B4 =D0=AE=D1=80=D1=8C=D0= =B5=D0=B2 (Leonid Yuriev) Another minor error seems a related typo in the calculation of `kcountsize`, but since kcounts are smaller than froms, this is actually to align the p->froms data. Co-authored-by: DJ Delorie diff --git a/gmon/gmon.c b/gmon/gmon.c index dee64803ad..bf76358d5b 100644 --- a/gmon/gmon.c +++ b/gmon/gmon.c @@ -132,6 +132,8 @@ __monstartup (u_long lowpc, u_long highpc) p->lowpc =3D ROUNDDOWN(lowpc, HISTFRACTION * sizeof(HISTCOUNTER)); p->highpc =3D ROUNDUP(highpc, HISTFRACTION * sizeof(HISTCOUNTER)); p->textsize =3D p->highpc - p->lowpc; + /* This looks like a typo, but it's here to align the p->froms + section. */ p->kcountsize =3D ROUNDUP(p->textsize / HISTFRACTION, sizeof(*p->froms))= ; p->hashfraction =3D HASHFRACTION; p->log_hashfraction =3D -1; @@ -142,7 +144,7 @@ __monstartup (u_long lowpc, u_long highpc) =09 instead of integer division. Precompute shift amount. */ p->log_hashfraction =3D ffs(p->hashfraction * sizeof(*p->froms)) - 1= ; } - p->fromssize =3D p->textsize / HASHFRACTION; + p->fromssize =3D ROUNDUP(p->textsize / HASHFRACTION, sizeof(*p->froms)); p->tolimit =3D p->textsize * ARCDENSITY / 100; if (p->tolimit < MINARCS) p->tolimit =3D MINARCS;