[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 25 Jan 2019 22:57:25 +0100
From: Szabolcs Nagy <nsz@...t70.net>
To: musl@...ts.openwall.com
Subject: Re: Infinite loop in malloc
* Markus Wichmann <nullplan@....net> [2019-01-25 22:49:29 +0100]:
> On Fri, Jan 25, 2019 at 10:13:50AM -0500, r yang wrote:
> > Examining the value in gdb:
> > (gdb) printf "%X\n", mask
> > 204701
> >
> > The bin head points to the bin itself so this condition is never met:
> > c = mal.bins[j].head;
> > if (c != BIN_TO_CHUNK(j)) { ... }
> >
> > Examining the values in gdb:
> > (gdb) printf "%X\n", mal.bins[j].head
> > 62337FC0
> > (gdb) printf "%X\n", (struct chunk *)((char *)(&mal.bins[j].head) - (2*sizeof(size_t)))
> > 62337FC0
>
> Wait, isn't that an invalid state? The bins are circular doubly linked
> lists; the head points back to itself only when the list is empty. But
> the binmap is only set for non-empty bins. At least in the
> single-threaded case.
>
> So, if the bit is 1, then it was never deleted. So either arm's
> a_and_64() is b0rken, or the last chunk removed from the smallest bin
it is not a 32bit process based on the backtrace.
it's most likely a qemu-arm running on x86_64.
so the problem is not arm's a_and_64.
it can be a concurrency bug that leaves mal.binmap corrupted.
> was invalid, and didn't trigger the a_and_64(). Or does anyone have a
> better idea?
>
> Ciao,
> Markus
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.
