[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 3 May 2022 11:47:09 -0400
From: Rich Felker <dalias@...c.org>
To: WILLIAMS Stephen <stephen.williams@...gemini.com>
Cc: "musl@...ts.openwall.com" <musl@...ts.openwall.com>
Subject: Re: BUG REPORT: Fault in src/malloc/oldmalloc/aligned_alloc.c
leads to memory corruption
On Tue, May 03, 2022 at 03:14:34PM +0000, WILLIAMS Stephen wrote:
> Interesting. From the logging I’m seeing (admittedly with an old
> fork in use with seL4) ‘mem’ is not guaranteed to be a multiple of
> SIZE_ALIGN as you are suggesting above.
>
> The following was generated with logging inside of the __memalign routine to show the values of ’new’ and ‘mem’:
>
> new = 0x5cd500
> mem = 0x5cd4f0
> memalign: align = 0x40, size = 0x1000. Returned address = 0x5cd500
>
> new = 0x5cd500
> mem = 0x5cd4f0
> memalign: align = 0x40, size = 0x1000. Returned address = 0x5cd500
>
> The ‘mem’ address returned by malloc is not a multiple of SIZE_ALIGN
> (32 on this system) thereby leading to new-mem being less that
> SIZE_ALIGN.
Interesting. I don't see where any changes were made to your fork of
malloc that would cause this, but it's definitely an intended variant
that all chunks be aligned mod SIZE_ALIGN, and that was the case all
the way back to the original musl oldmalloc.
Is it possible that PAGE_SIZE is evaluating to nonsense (maybe
libc.page_size ununitialized), resulting in the initial brk not
getting aligned? It's an implicit assumption that page size is larger
than SIZE_ALIGN.
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
