[Bug libc/29444] New: gmon memory corruption due wrong calculation of required buffer size

[Bug libc/29444] New: gmon memory corruption due wrong calculation of required buffer size

[leo at yuriev dot ru]

https://sourceware.org/bugzilla/show_bug.cgi?id=29444

            Bug ID: 29444
           Summary: gmon memory corruption due wrong calculation of
                    required buffer size
           Product: glibc
           Version: 2.38
            Status: UNCONFIRMED
          Severity: critical
          Priority: P2
         Component: libc
          Assignee: unassigned at sourceware dot org
          Reporter: leo at yuriev dot ru
                CC: drepper.fsp at gmail dot com
  Target Milestone: ---

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))`.

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 Bug 29438.

Another minor error seems a related typo in the calculation of `kcountsize`.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libc/29444] gmon memory corruption due wrong calculation of required buffer size

[leo at yuriev dot ru]

https://sourceware.org/bugzilla/show_bug.cgi?id=29444

--- Comment #1 from Leo Yuriev <leo at yuriev dot ru> ---
Created attachment 14253
  --> https://sourceware.org/bugzilla/attachment.cgi?id=14253&action=edit
the patch

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libc/29444] gmon memory corruption due wrong calculation of required buffer size

[leo at yuriev dot ru]

https://sourceware.org/bugzilla/show_bug.cgi?id=29444

--- Comment #2 from Leo Yuriev <leo at yuriev dot ru> ---
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.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libc/29444] gmon memory corruption due wrong calculation of required buffer size

[pinskia at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=29444

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           See Also|                            |https://sourceware.org/bugz
                   |                            |illa/show_bug.cgi?id=27576

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libc/29444] gmon memory corruption due wrong calculation of required buffer size

[leo at yuriev dot ru]

https://sourceware.org/bugzilla/show_bug.cgi?id=29444

--- Comment #3 from Leo Yuriev <leo at yuriev dot ru> ---
Please review the attached patch and apply. 
It just fixes an allocated buffer overrun issue, i.e. the memory corruption!

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libc/29444] gmon memory corruption due wrong calculation of required buffer size

[adhemerval.zanella at linaro dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=29444

Adhemerval Zanella <adhemerval.zanella at linaro dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |adhemerval.zanella at linaro dot o
                   |                            |rg

--- Comment #4 from Adhemerval Zanella <adhemerval.zanella at linaro dot org> ---
(In reply to Leo Yuriev from comment #3)
> Please review the attached patch and apply. 
> It just fixes an allocated buffer overrun issue, i.e. the memory corruption!

Patch reviews are done through libc-alpha email list, could you please sent the
patch following the contribution guidelines [1]?

[1] https://sourceware.org/glibc/wiki/Contribution%20checklist

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libc/29444] gmon memory corruption due wrong calculation of required buffer size

[leo at yuriev dot ru]

https://sourceware.org/bugzilla/show_bug.cgi?id=29444

--- Comment #5 from Leo Yuriev <leo at yuriev dot ru> ---
https://patchwork.sourceware.org/project/glibc/patch/20230204114138.5436-1-leo@yuriev.ru/

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libc/29444] gmon memory corruption due wrong calculation of required buffer size

[leo at yuriev dot ru]

https://sourceware.org/bugzilla/show_bug.cgi?id=29444

--- Comment #6 from Leo Yuriev <leo at yuriev dot ru> ---
CVE-ID was requested via submission to VulDB.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libc/29444] gmon memory corruption due wrong calculation of required buffer size

[leo at yuriev dot ru]

https://sourceware.org/bugzilla/show_bug.cgi?id=29444

Leo Yuriev <leo at yuriev dot ru> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dj at redhat dot com

--- Comment #7 from Leo Yuriev <leo at yuriev dot ru> ---
CVE-2023-0687
https://vuldb.com/?id.220246

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libc/29444] gmon memory corruption due wrong calculation of required buffer size

[fweimer at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=29444

Florian Weimer <fweimer at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |fweimer at redhat dot com
           Severity|critical                    |minor

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libc/29444] gmon memory corruption due wrong calculation of required buffer size

[ismail at i10z dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=29444

Ismail Donmez <ismail at i10z dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ismail at i10z dot com

--- Comment #8 from Ismail Donmez <ismail at i10z dot com> ---
Will the glibc maintainers reject the assigned CVE? I don't see how this is
exploitable.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libc/29444] gmon memory corruption due wrong calculation of required buffer size

[fweimer at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=29444

--- Comment #9 from Florian Weimer <fweimer at redhat dot com> ---
(In reply to Ismail Donmez from comment #8)
> Will the glibc maintainers reject the assigned CVE? I don't see how this is
> exploitable.

Agreed. I expect us to file a DISPUTE request with MITRE later today.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libc/29444] gmon memory corruption due wrong calculation of required buffer size

[leo at yuriev dot ru]

https://sourceware.org/bugzilla/show_bug.cgi?id=29444

--- Comment #10 from Leo Yuriev <leo at yuriev dot ru> ---
(In reply to Florian Weimer from comment #9)
> (In reply to Ismail Donmez from comment #8)
> > Will the glibc maintainers reject the assigned CVE? I don't see how this is
> > exploitable.
> 
> Agreed. I expect us to file a DISPUTE request with MITRE later today.

Yes, it is not exploitable in usual/common cases.

However, this bug can be exploited in rare specific scenarios when monstartup()
and moncontrol() are called explicitly to collect statistics from a part of
modules compiled with the corresponding options (nonetheless, I cannot disclose
information about affected software either show the exploit).

During submission for CVE-ID, I noted about that the bug could be exploited
only when gmon activated, but such note is not included into CVE for now.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libc/29444] gmon memory corruption due wrong calculation of required buffer size

[siddhesh at sourceware dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=29444

Siddhesh Poyarekar <siddhesh at sourceware dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |siddhesh at sourceware dot org
              Flags|                            |security-

--- Comment #11 from Siddhesh Poyarekar <siddhesh at sourceware dot org> ---
The only way to induce this buffer overflow is to modify the callgraph of an
application that is built with these options(In reply to Leo Yuriev from
comment #10)
> (In reply to Florian Weimer from comment #9)
> > (In reply to Ismail Donmez from comment #8)
> > > Will the glibc maintainers reject the assigned CVE? I don't see how this is
> > > exploitable.
> > 
> > Agreed. I expect us to file a DISPUTE request with MITRE later today.
> 
> Yes, it is not exploitable in usual/common cases.
> 
> However, this bug can be exploited in rare specific scenarios when
> monstartup() and moncontrol() are called explicitly to collect statistics
> from a part of modules compiled with the corresponding options (nonetheless,
> I cannot disclose information about affected software either show the
> exploit).

The inputs that induce this buffer overflow are basically addresses of the
running application that is built with gmon enabled *and* with the patch for
bug 29438, so it's basically trusted input or input that needs an actual
security flaw to be compromised or controlled.  The bug needs to be fixed, but
there's no security issue here.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libc/29444] gmon memory corruption due wrong calculation of required buffer size

[leo at yuriev dot ru]

https://sourceware.org/bugzilla/show_bug.cgi?id=29444

--- Comment #12 from Leo Yuriev <leo at yuriev dot ru> ---
(In reply to Siddhesh Poyarekar from comment #11)
> The inputs that induce this buffer overflow are basically addresses of the
> running application that is built with gmon enabled *and* with the patch for
> bug 29438, so it's basically trusted input or input that needs an actual
> security flaw to be compromised or controlled.  The bug needs to be fixed,
> but there's no security issue here.

The patch for Bug 29438 not needed to exploitation, but gmon must be enabled.
Initially I discovered this issue while working on Bug 29438.
But later it was re-noticed in another environment, where it is exploitable.

Briefly:
1) Prerequirement:
 - a web service users gmon to collect statistics on the performance of its
module(s);
 - OR an attacker can enable the collection of such statistics;
2) By manipulating requests, the attacker achieves a function call that is at
the end of the monitored addresses and is usually never called. T
3) The attacker continue an attack using memory corruption.

Yes, this is a very specific scenario with a very low probability of
exploitation.
However, we reproduced it in a prepared environment.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libc/29444] gmon memory corruption due wrong calculation of required buffer size

[siddhesh at sourceware dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=29444

--- Comment #13 from Siddhesh Poyarekar <siddhesh at sourceware dot org> ---
(In reply to Leo Yuriev from comment #12)
> 2) By manipulating requests, the attacker achieves a function call that is
> at the end of the monitored addresses and is usually never called. T

My point is that this step above needs specific knowledge of the address space
*and* control over execution to make this happen.  Without such control,
there's no exploitation vector.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libc/29444] gmon memory corruption due wrong calculation of required buffer size

[leo at yuriev dot ru]

https://sourceware.org/bugzilla/show_bug.cgi?id=29444

--- Comment #14 from Leo Yuriev <leo at yuriev dot ru> ---
(In reply to Siddhesh Poyarekar from comment #13)
> (In reply to Leo Yuriev from comment #12)
> > 2) By manipulating requests, the attacker achieves a function call that is
> > at the end of the monitored addresses and is usually never called.
> 
> My point is that this step above needs specific knowledge of the address
> space *and* control over execution to make this happen.  Without such
> control, there's no exploitation vector.

There is the effect of a "critical mass" of vulnerabilities - when exploitation
is possible only if there is a set of vulnerabilities, but not one or even two.

In my case, it took a couple more vulnerabilities in the application code to
exploit this bug. However, without this issue, exploiting is also impossible.

My point is: we cannot assume all use cases and scenarios for a widely used
library, therefore a use-after-free, off-by-one, buffer overflow, memory
corruption, using/reading uninitialized, race condition, etc... in a such
library is always a CVE.
No options.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libc/29444] gmon memory corruption due wrong calculation of required buffer size

[siddhesh at sourceware dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=29444

--- Comment #15 from Siddhesh Poyarekar <siddhesh at sourceware dot org> ---
(In reply to Leo Yuriev from comment #14)
> There is the effect of a "critical mass" of vulnerabilities - when
> exploitation is possible only if there is a set of vulnerabilities, but not
> one or even two.
> 
> In my case, it took a couple more vulnerabilities in the application code to
> exploit this bug. However, without this issue, exploiting is also impossible.

Please explain how, remember that the input has to be *untrusted* for it to be
considered a security issue.

> My point is: we cannot assume all use cases and scenarios for a widely used
> library, therefore a use-after-free, off-by-one, buffer overflow, memory
> corruption, using/reading uninitialized, race condition, etc... in a such
> library is always a CVE.
> No options.

You're free to consider every memory or synchronization bug in libraries you
use as a security issue and deal with it as such.  In the glibc project we have
well defined rules as to what we consider security issues:

https://sourceware.org/glibc/wiki/Security%20Process

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libc/29444] gmon memory corruption due wrong calculation of required buffer size

[leo at yuriev dot ru]

https://sourceware.org/bugzilla/show_bug.cgi?id=29444

Leo Yuriev <leo at yuriev dot ru> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |NOTABUG

--- Comment #16 from Leo Yuriev <leo at yuriev dot ru> ---
Sorry, but I don't have time for useless discuss.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libc/29444] gmon memory corruption due wrong calculation of required buffer size

[siddhesh at sourceware dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=29444

Siddhesh Poyarekar <siddhesh at sourceware dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|NOTABUG                     |---
             Status|RESOLVED                    |UNCONFIRMED

--- Comment #17 from Siddhesh Poyarekar <siddhesh at sourceware dot org> ---
Keeping the bug open since we obviously want to fix it.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libc/29444] gmon memory corruption due wrong calculation of required buffer size

[carnil at debian dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=29444

Salvatore Bonaccorso <carnil at debian dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |carnil at debian dot org

--- Comment #18 from Salvatore Bonaccorso <carnil at debian dot org> ---
Florian,

Regarding the DISPUTE (or reject?) for the CVE as mentioned in
https://sourceware.org/bugzilla/show_bug.cgi?id=29444#c9 : 

Schould the request actually go to VulDB instead of MITRE, as
VulDB was the assigning CNA?

Regards,
Salvatore

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libc/29444] gmon memory corruption due wrong calculation of required buffer size

[siddhesh at sourceware dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=29444

--- Comment #19 from Siddhesh Poyarekar <siddhesh at sourceware dot org> ---
I already submitted the rejection request to Mitre.  VulDB has a login barrier
to even view the CVE, so I didn't bother with it.  If Mitre refuses to handle
it I'll retry with vuldb.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libc/29444] gmon memory corruption due wrong calculation of required buffer size

[jamborm at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=29444

Martin Jambor <jamborm at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jamborm at gcc dot gnu.org

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libc/29444] gmon memory corruption due wrong calculation of required buffer size

[leo at yuriev dot ru]

https://sourceware.org/bugzilla/show_bug.cgi?id=29444

--- Comment #20 from account disabled by myself since useless <leo at yuriev dot ru> ---
Fixed by commit 801af9fafd4689337ebf27260aa115335a0cb2bc
https://sourceware.org/git/?p=glibc.git;a=commit;h=801af9fafd4689337ebf27260aa115335a0cb2bc

Thanks to DJ Delorie <dj@redhat.com>.

Please close as FIXED.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libc/29444] gmon memory corruption due wrong calculation of required buffer size

[dj at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=29444

dj at redhat dot com <dj at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
             Status|UNCONFIRMED                 |RESOLVED

--- Comment #21 from dj at redhat dot com <dj at redhat dot com> ---
Fixed in rawhide.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libc/29444] gmon memory corruption due wrong calculation of required buffer size

[linzhuorong at huawei dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=29444

lin zhuorong <linzhuorong at huawei dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |linzhuorong at huawei dot com

--- Comment #22 from lin zhuorong <linzhuorong at huawei dot com> ---
(In reply to account disabled by myself since useless from comment #20)
> Fixed by commit 801af9fafd4689337ebf27260aa115335a0cb2bc
> https://sourceware.org/git/?p=glibc.git;a=commit;
> h=801af9fafd4689337ebf27260aa115335a0cb2bc
> 
> Thanks to DJ Delorie <dj@redhat.com>.
> 
> Please close as FIXED.

This fix calls ROUNDUP to address memory alignment and does not limit the
buffer size to the specified range.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libc/29444] gmon memory corruption due wrong calculation of required buffer size

[dj at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=29444

--- Comment #23 from dj at redhat dot com <dj at redhat dot com> ---
Could you be more specific?  (In reply to lin zhuorong from comment #22)
> This fix calls ROUNDUP to address memory alignment and does not limit the
> buffer size to the specified range.

Could you be more specific?  The fix increases the buffer size enough to
prevent a partial record from being written past the end of the allocated
buffer.  The memory alignment was already in there.  Which range should the
buffer size be limited to?

-- 
You are receiving this mail because:
You are on the CC list for the bug.