public inbox for glibc-bugs@sourceware.org help / color / mirror / Atom feed
From: "dimosxakis0 at gmail dot com" <sourceware-bugzilla@sourceware.org> To: glibc-bugs@sourceware.org Subject: [Bug malloc/29710] New: Multiple integer overflows on 'memusage.c' Date: Thu, 20 Oct 2022 19:06:00 +0000 [thread overview] Message-ID: <bug-29710-131@http.sourceware.org/bugzilla/> (raw) https://sourceware.org/bugzilla/show_bug.cgi?id=29710 Bug ID: 29710 Summary: Multiple integer overflows on 'memusage.c' Product: glibc Version: 2.36 Status: UNCONFIRMED Severity: minor Priority: P2 Component: malloc Assignee: unassigned at sourceware dot org Reporter: dimosxakis0 at gmail dot com Target Milestone: --- Multiple integer overflows exist on the malloc/calloc wrapper implementations on 'memusage.c'. void * calloc (size_t n, size_t len) { struct header *result; size_t size = n * len; // (1) ... /* Do the real work. */ result = (struct header *) (*mallocp)(size + sizeof (struct header)); // (2) ... return memset (result + 1, '\0', size); } At (1) there is no check for integer overflow. At (2) size is also padded with a header size that might cause an additional integer overflow if (1) is fixed. Eventually the computed size will be passed to the real malloc which will return a small chunk instead of failing with NULL. Similarly in the malloc wrapper there is another integer overflow: void * malloc (size_t len) { ... /* Do the real work. */ result = (struct header *) (*mallocp)(len + sizeof (struct header)); // (3) ... /* Return the pointer to the user buffer. */ return (void *) (result + 1); } At (3) len is padded with the size of the header which may cause an integer overflow returning a small chunk instead of failing with NULL. Fortunately libmemusage.so as far as I know is only used from the linux memusage command. Which is rarely used from anyone in practice. The only scenario that possibly this can introduce security risk to a system, is if attacker controllable input is passed to a program that is being profiled with 'memusage' command. If the attacker controls any malloc/calloc size fields then he could cause a heap overflow and possibly compromise the system. This is unluckily due to the rare usage of memusage. An PoC example that can be used to verify this behavior is given below: #include <stdio.h> #include <string.h> #include <stdlib.h> int main(int argc, char** argv) { char* overflow_chunk = malloc(0xffffffffffffffff); char* overflowed_chunk = malloc(0x18); if(overflow_chunk != NULL) { // If we reached this far this is bad. Possible corruption ahead of us. memset(overflow_chunk, 'A', 40); } else { puts("malloc() failed as it should in this case."); } // Should cause an abort due to chunk size corruption in case of an integer overflow. free(overflowed_chunk); free(overflow_chunk); return 0; } Running the above program with: $ gcc test.c -o a.out $ memusage ./a.out We should get an abortion error like this: double free or corruption (out) -- You are receiving this mail because: You are on the CC list for the bug.
reply other threads:[~2022-10-20 19:06 UTC|newest] Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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-29710-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).