From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pj1-x102a.google.com (mail-pj1-x102a.google.com [IPv6:2607:f8b0:4864:20::102a]) by sourceware.org (Postfix) with ESMTPS id EAE483858D1E for ; Fri, 10 Mar 2023 12:34:46 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org EAE483858D1E Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-pj1-x102a.google.com with SMTP id 6-20020a17090a190600b00237c5b6ecd7so9596290pjg.4 for ; Fri, 10 Mar 2023 04:34:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1678451686; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=8gjdy+CpqmlmDVyrDnbmZSWrSgWWlRk0CaxCR6GAPho=; b=ZzpL9lgghoZbHEfYfvOqwDELiBPnU2ZyQsoWspifs62h2W45AruXvnmpyU7UeQbbuL mcjk3rVxvnazWHrFSF6Mn9gw9zx3p+vYclj981QykvyvuQkCNGrEl1UkW4vpVJoofXeN w/Zn4jcxwnuF6EigIA7Y38JnncY/dECrkmm6upxb6tqzsN7oCpubl/9uzMaRyFc7i6aM TCxXUnnymb0YUXZ8TtzGMk961EWIXXHpFM6XHoswavFMDgLLp0es/MVsfDb4Om40Tq63 tvI+NtfUDzpxlkX3ExluOSKOHSqjEaNN46k+1r/Lr+NS2BEUu1s8fuST1qcZ1N9hRpzZ ojWQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1678451686; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=8gjdy+CpqmlmDVyrDnbmZSWrSgWWlRk0CaxCR6GAPho=; b=hC2ZXFZfcnrzHQvlJ+wtcS8qQnaT/GyLAtxpmEtf8Q/cKpqIwYBPjh7cIAmwFPWokl kHcZI2bqvf7x9t7KDJ3KQ3RzAlZNUgvh9NxWF177AyP41G2fdisNzfN02VA4yJKFsJ0y 6vHtNtyB83FvKOYUmBaeF+T6i2MjXOCJoID7OEaHeLH7SgNSMlpS49k8KiIbbqiuQBaV jrn9/aXjVkR6qxaefhQuaiQP4g7arf8CVYT7By4pJh0L85QKSahy1D4GDOsql0yQk+Fv u5uEf/USGKeoomEumBUV6nJAXHV829L5Nim3G/unMrlTg7hz2GA8hX279gHI2w3sBxX1 CMuw== X-Gm-Message-State: AO0yUKULWWUUAOxUFpm0XRxlkI94qfpEuJgo0b0FBjsHrFimBS+aIHav V2FLUGmTN9qAzLwrVZO0u5QYh7uf9U0= X-Google-Smtp-Source: AK7set83rYsYZKhAZdW9oSooPfgJ1jqhbss4+Q8Fy7V5Ia+OD9wxq6bIfv1DZoDShVNfrpADaLQp3Q== X-Received: by 2002:a05:6a20:9390:b0:c6:ff46:c713 with SMTP id x16-20020a056a20939000b000c6ff46c713mr31329596pzh.57.1678451685717; Fri, 10 Mar 2023 04:34:45 -0800 (PST) Received: from bft-PowerEdge-R620.. ([49.204.85.206]) by smtp.gmail.com with ESMTPSA id j4-20020aa78dc4000000b005a8bf239f5csm1327323pfr.193.2023.03.10.04.34.44 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 10 Mar 2023 04:34:45 -0800 (PST) From: Yash Shinde To: libc-stable@sourceware.org Cc: Yash.Shinde@windriver.com, Randy.MacLeod@windriver.com Subject: [COMMITTED] gmon: Fix allocated buffer overflow (bug 29444) Date: Fri, 10 Mar 2023 18:04:20 +0530 Message-Id: <20230310123420.3368386-1-yashinde145@gmail.com> X-Mailer: git-send-email 2.34.1 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-10.9 required=5.0 tests=BAYES_00,BODY_8BITS,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,GIT_PATCH_0,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,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: 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 instructions 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)); 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) 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 Reviewed-by: Carlos O'Donell Request to backport this patch to branch release/2.35/master and other released branches, as this is a bug for all glibc users using older versions of glibc. Suggested-by: Yash Shinde --- gmon/gmon.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) 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 = ROUNDDOWN(lowpc, HISTFRACTION * sizeof(HISTCOUNTER)); p->highpc = ROUNDUP(highpc, HISTFRACTION * sizeof(HISTCOUNTER)); p->textsize = p->highpc - p->lowpc; + /* This looks like a typo, but it's here to align the p->froms + section. */ p->kcountsize = ROUNDUP(p->textsize / HISTFRACTION, sizeof(*p->froms)); p->hashfraction = HASHFRACTION; p->log_hashfraction = -1; @@ -142,7 +144,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; -- 2.34.1