[Bug malloc/25733] New: mallopt(M_MXFAST) can set global_max_fast to 0

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

[Bug malloc/25733] New: mallopt(M_MXFAST) can set global_max_fast to 0

Sourceware - glibc-bugs mailing list
https://sourceware.org/bugzilla/show_bug.cgi?id=25733

            Bug ID: 25733
           Summary: mallopt(M_MXFAST) can set global_max_fast to 0
           Product: glibc
           Version: 2.31
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: malloc
          Assignee: unassigned at sourceware dot org
          Reporter: maxkamper at outlook dot com
  Target Milestone: ---

mallopt(M_MXFAST) can set global_max_fast to 0.

This doesn't seem intentional because mallopt(M_MXFAST, 0) sets global_max_fast
to SMALLBIN_WIDTH.

Passing a value between 1-7 to mallopt(M_MXFAST, value) sets global_max_fast to
0.

Both malloc.c and the mallopt man page document the legitimate range of values
that may be passed to mallopt(M_MXFAST, value) as "0 to 80*sizeof(size_t)/4".

In GLIBC versions >= 2.27 this has the same effect as setting global_max_fast
to SMALLBIN_WIDTH, but it is perhaps of some concern in GLIBC versions <= 2.26
because of how global_max_fast is treated as an indicator of main arena
initialization by malloc_consolidate().

If the following example is compiled & run under GLIBC version 2.26, a chunk is
allocated overlapping the main arena:

#include <stdio.h>
#include <stdlib.h>
#include <malloc.h>

int main(void) {

    // Populate last_remainder, which is treated as the top chunk size field
    // after main arena re-initialization.
    void* remainder_me = malloc(0x418);
    malloc(0x18); // Avoid top chunk consolidation.
    free(remainder_me);
    malloc(0x18); // Remainder remainder_me chunk.

    // Set global_max_fast to 0.
    mallopt(M_MXFAST, 7);

    // Trigger malloc_consolidate(), which could happen during large
    // allocations/frees, but for the sake of simplicity here just call
    // mallopt() again.
    mallopt(M_MXFAST, 0x78);

    // malloc_consolidate() uses global_max_fast to determine if malloc has
    // been initialized. If global_max_fast is 0, malloc_consolidate() will
    // re-initialize the main arena, setting its top chunk pointer to an
address
    // within the main arena. Now last_remainder acts as the top chunk size
    // field.
    printf("%p\n", malloc(0x418);

    return 0;
}

--
You are receiving this mail because:
You are on the CC list for the bug.
Reply | Threaded
Open this post in threaded view
|

[Bug malloc/25733] mallopt(M_MXFAST) can set global_max_fast to 0

Sourceware - glibc-bugs mailing list
https://sourceware.org/bugzilla/show_bug.cgi?id=25733

--- Comment #1 from Max <maxkamper at outlook dot com> ---
The printf() statement is missing a closing bracket.

--
You are receiving this mail because:
You are on the CC list for the bug.
Reply | Threaded
Open this post in threaded view
|

[Bug malloc/25733] mallopt(M_MXFAST) can set global_max_fast to 0

Sourceware - glibc-bugs mailing list
In reply to this post by Sourceware - glibc-bugs mailing list
https://sourceware.org/bugzilla/show_bug.cgi?id=25733

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
                 CC|                            |dj at redhat dot com
     Ever confirmed|0                           |1
   Last reconfirmed|                            |2020-03-31

--- Comment #2 from dj at redhat dot com <dj at redhat dot com> ---
It looks like changing "s == 0" to "s < SMALLBIN_WIDTH" in the set_max_fast()
macro (around line 1622 in malloc/malloc.c) ensures that global_max_fast is
never set to zero.  This fix should apply and work for all current glibc
versions.

--
You are receiving this mail because:
You are on the CC list for the bug.
Reply | Threaded
Open this post in threaded view
|

[Bug malloc/25733] mallopt(M_MXFAST) can set global_max_fast to 0

Sourceware - glibc-bugs mailing list
In reply to this post by Sourceware - glibc-bugs mailing list
https://sourceware.org/bugzilla/show_bug.cgi?id=25733

Carlos O'Donell <carlos at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |carlos at redhat dot com
              Flags|                            |security-

--- Comment #3 from Carlos O'Donell <carlos at redhat dot com> ---
(In reply to [hidden email] from comment #2)
> It looks like changing "s == 0" to "s < SMALLBIN_WIDTH" in the
> set_max_fast() macro (around line 1622 in malloc/malloc.c) ensures that
> global_max_fast is never set to zero.  This fix should apply and work for
> all current glibc versions.

Is this issue a security defect?

How likely is it that someone would call mallopt(M_MXFAST, <a value of 1-7>)?

I will argue that I think it is very unlikely someone would use this interface
with those values, so therefore I don't think this is a security bug.

--
You are receiving this mail because:
You are on the CC list for the bug.
Reply | Threaded
Open this post in threaded view
|

[Bug malloc/25733] mallopt(M_MXFAST) can set global_max_fast to 0

Sourceware - glibc-bugs mailing list
In reply to this post by Sourceware - glibc-bugs mailing list
https://sourceware.org/bugzilla/show_bug.cgi?id=25733

--- Comment #4 from dj at redhat dot com <dj at redhat dot com> ---
I don't see a way of setting max fast from outside the application - 2.26 is
pre-mxfast-tunable and 2.27 is post-bug.  If a specific application calls
mallopt in a way to cause a security problem, IMHO that's the app's problem.

--
You are receiving this mail because:
You are on the CC list for the bug.
Reply | Threaded
Open this post in threaded view
|

[Bug malloc/25733] mallopt(M_MXFAST) can set global_max_fast to 0

Sourceware - glibc-bugs mailing list
In reply to this post by Sourceware - glibc-bugs mailing list
https://sourceware.org/bugzilla/show_bug.cgi?id=25733

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Assignee|unassigned at sourceware dot org   |dj at redhat dot com

--
You are receiving this mail because:
You are on the CC list for the bug.
Reply | Threaded
Open this post in threaded view
|

[Bug malloc/25733] mallopt(M_MXFAST) can set global_max_fast to 0

Sourceware - glibc-bugs mailing list
In reply to this post by Sourceware - glibc-bugs mailing list
https://sourceware.org/bugzilla/show_bug.cgi?id=25733

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

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

--- Comment #5 from dj at redhat dot com <dj at redhat dot com> ---
Fixed in master.  Patch should be trivially back-portable to many branches.

--
You are receiving this mail because:
You are on the CC list for the bug.
Reply | Threaded
Open this post in threaded view
|

[Bug malloc/25733] mallopt(M_MXFAST) can set global_max_fast to 0

Sourceware - glibc-bugs mailing list
In reply to this post by Sourceware - glibc-bugs mailing list
https://sourceware.org/bugzilla/show_bug.cgi?id=25733

Joseph Myers <jsm28 at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |2.32

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