From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id B7FC63858439; Wed, 22 Feb 2023 22:24:27 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org B7FC63858439 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1677104667; bh=iWrU5WqxQTorEgH/ymsetZR9Ibu3VTohduy6FGBB8So=; h=From:To:Subject:Date:In-Reply-To:References:From; b=YbbxChrXivAwRO/1qes6Nsc1fkVo7ctyXF7LGIG6MrsP1sT15gs2trzc4XzyTur9p GKnsbN5YhZaRa0VysyXG5Rg0hxZ2lXVhKdRMxxdTohdSbTAhx/i4vDtwVdgW0qMcgE gZ0pJ+hxFi/qisreDcBkLD0hUSwXr/ZTHvPtqM30= From: "cvs-commit at gcc dot gnu.org" To: glibc-bugs@sourceware.org Subject: [Bug libc/29438] enabling gmon for arbitrary DSO Date: Wed, 22 Feb 2023 22:24:26 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: glibc X-Bugzilla-Component: libc X-Bugzilla-Version: 2.38 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: cvs-commit at gcc dot gnu.org X-Bugzilla-Status: RESOLVED X-Bugzilla-Resolution: WONTFIX X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 List-Id: https://sourceware.org/bugzilla/show_bug.cgi?id=3D29438 --- Comment #6 from cvs-commit at gcc dot gnu.org --- The master branch has been updated by DJ Delorie : https://sourceware.org/git/gitweb.cgi?p=3Dglibc.git;h=3D801af9fafd4689337eb= f27260aa115335a0cb2bc commit 801af9fafd4689337ebf27260aa115335a0cb2bc Author: =C3=90=C3=90=C2=B5=C3=90=C2=BE=C3=90=C2=BD=C3=90=C2=B8=C3=90=C2=B4 = =C3=90=C2=AE=C3=91=C3=91=C3=90=C2=B5=C3=90=C2=B2 (Leonid Yuriev) Date: Sat Feb 4 14:41:38 2023 +0300 gmon: Fix allocated buffer overflow (bug 29444) 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 =3D p->textsize / HASHFRACTION; but actually should be p->fromssize =3D ROUNDUP(p->textsize / HASHFRACTION, sizeof(*p->from= s)); 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=3D2= 9438 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: =C3=90=C3=90=C2=B5=C3=90=C2=BE=C3=90=C2=BD=C3=90=C2=B8= =C3=90=C2=B4 =C3=90=C2=AE=C3=91=C3=91=C3=90=C2=B5=C3=90=C2=B2 (Leonid Yurie= v) 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 --=20 You are receiving this mail because: You are on the CC list for the bug.=