public inbox for glibc-bugs@sourceware.org help / color / mirror / Atom feed
From: "maxkamper at outlook dot com" <sourceware-bugzilla@sourceware.org> To: glibc-bugs@sourceware.org Subject: [Bug malloc/25733] New: mallopt(M_MXFAST) can set global_max_fast to 0 Date: Thu, 26 Mar 2020 17:36:07 +0000 [thread overview] Message-ID: <bug-25733-131@http.sourceware.org/bugzilla/> (raw) 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.
next reply other threads:[~2020-03-26 17:36 UTC|newest] Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-03-26 17:36 maxkamper at outlook dot com [this message] 2020-03-26 17:41 ` [Bug malloc/25733] " maxkamper at outlook dot com 2020-03-31 17:16 ` dj at redhat dot com 2020-03-31 17:30 ` carlos at redhat dot com 2020-03-31 17:44 ` dj at redhat dot com 2020-04-06 20:27 ` dj at redhat dot com 2020-04-06 21:04 ` dj at redhat dot com 2020-07-08 16:47 ` jsm28 at gcc dot gnu.org
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-25733-131@http.sourceware.org/bugzilla/ \ --to=sourceware-bugzilla@sourceware.org \ --cc=glibc-bugs@sourceware.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).