From patchwork Sat Feb 4 11:41:38 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: =?utf-8?b?0JvQtdC+0L3QuNC0INCu0YDRjNC10LIgKExlb25pZCBZdXJpZXYp?= X-Patchwork-Id: 64295 X-Patchwork-Delegate: dj@redhat.com Return-Path: X-Original-To: patchwork@sourceware.org Delivered-To: patchwork@sourceware.org Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 4D9743857B93 for ; Sat, 4 Feb 2023 11:45:02 +0000 (GMT) X-Original-To: libc-alpha@sourceware.org Delivered-To: libc-alpha@sourceware.org Received: from forward105j.mail.yandex.net (forward105j.mail.yandex.net [5.45.198.248]) by sourceware.org (Postfix) with ESMTPS id EEBDA3858C52 for ; Sat, 4 Feb 2023 11:44:47 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org EEBDA3858C52 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=yuriev.ru Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=yuriev.ru Received: from myt5-fc73f9af8654.qloud-c.yandex.net (myt5-fc73f9af8654.qloud-c.yandex.net [IPv6:2a02:6b8:c12:2898:0:640:fc73:f9af]) by forward105j.mail.yandex.net (Yandex) with ESMTP id CA0414EC9D41; Sat, 4 Feb 2023 14:42:04 +0300 (MSK) Received: by myt5-fc73f9af8654.qloud-c.yandex.net (smtp/Yandex) with ESMTPSA id 3gXq2nuYUeA1-Wq7BS5Pl; Sat, 04 Feb 2023 14:42:04 +0300 X-Yandex-Fwd: 1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yuriev.ru; s=mail; t=1675510924; bh=LuWTLecar1PYenEgGzogYr2tcw5irV5ynX8LLQqxkiM=; h=Message-Id:Date:Cc:Subject:To:From; b=LgHZzbyfIP+mKyV23CMp5Yudx15MlDvMdzZ3ufTM7fP0E3+8jpH2ETixzpXt5Vu8/ +4SZgPBSjc0DOaMs7HzL89V9Z+Erq7w5G4ieN8UQEdJYfRoXHW+khJzjsRby+nyBsQ vXJbOiK1iP88HzK3arWlYlgsUtqMotGzwKiC1Mls= Authentication-Results: myt5-fc73f9af8654.qloud-c.yandex.net; dkim=pass header.i=@yuriev.ru From: =?utf-8?b?0JvQtdC+0L3QuNC0INCu0YDRjNC10LIgKExlb25pZCBZdXJpZXYp?= To: libc-alpha@sourceware.org Cc: drepper.fsp@gmail.com, =?utf-8?b?0JvQtdC+0L3QuNC0INCu0YDRjNC10LIgKExl?= =?utf-8?b?b25pZCBZdXJpZXYp?= Subject: [PATCH] gmon: Fix allocated buffer overflow (bug 2944) Date: Sat, 4 Feb 2023 14:41:38 +0300 Message-Id: <20230204114138.5436-1-leo@yuriev.ru> X-Mailer: git-send-email 2.34.1 MIME-Version: 1.0 X-Spam-Status: No, score=-10.3 required=5.0 tests=BAYES_00, BODY_8BITS, DKIM_INVALID, DKIM_SIGNED, GIT_PATCH_0, KAM_DMARC_STATUS, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: libc-alpha-bounces+patchwork=sourceware.org@sourceware.org Sender: "Libc-alpha" 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 = p->textsize / HASHFRACTION; but actually should be p->fromssize = ROUNDUP(p->textsize / HASHFRACTION, sizeof(*p->froms)); Another minor error seems a related typo in the calculation of `kcountsize`. 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=29438 Just in case, I will explicitly note that the problem breaks the `make test t=gmon/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: Леонид Юрьев (Leonid Yuriev) --- gmon/gmon.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/gmon/gmon.c b/gmon/gmon.c index dee64803ad..4712d9f66b 100644 --- a/gmon/gmon.c +++ b/gmon/gmon.c @@ -132,7 +132,7 @@ __monstartup (u_long lowpc, u_long highpc) p->lowpc = ROUNDDOWN(lowpc, HISTFRACTION * sizeof(HISTCOUNTER)); p->highpc = ROUNDUP(highpc, HISTFRACTION * sizeof(HISTCOUNTER)); p->textsize = p->highpc - p->lowpc; - p->kcountsize = ROUNDUP(p->textsize / HISTFRACTION, sizeof(*p->froms)); + p->kcountsize = ROUNDUP(p->textsize / HISTFRACTION, sizeof(*p->kcount)); p->hashfraction = HASHFRACTION; p->log_hashfraction = -1; /* The following test must be kept in sync with the corresponding @@ -142,7 +142,7 @@ __monstartup (u_long lowpc, u_long highpc) instead of integer division. Precompute shift amount. */ p->log_hashfraction = ffs(p->hashfraction * sizeof(*p->froms)) - 1; } - p->fromssize = p->textsize / HASHFRACTION; + p->fromssize = ROUNDUP(p->textsize / HASHFRACTION, sizeof(*p->froms)); p->tolimit = p->textsize * ARCDENSITY / 100; if (p->tolimit < MINARCS) p->tolimit = MINARCS;