|
Message-ID: <20220503154709.GV7074@brightrain.aerifal.cx> 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.