[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20180605055848.GB1392@brightrain.aerifal.cx>
Date: Tue, 5 Jun 2018 01:58:48 -0400
From: dalias <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: 回复：SIGSEGV and SIGILL
at malloc/free on ARM926
On Tue, Jun 05, 2018 at 11:24:34AM +0800, 徐露 wrote:
>
> Mon, 4 Jun 2018 05:41:29 -0400, Rich Felker <dalias@...c.org> wrote:
> > Looks like classic double-free.
> The program crashes randomly. If it is double free, it will may
> crash at the same place or same time.
Only if the program completely lacks any concurrency. If it's
multithreaded, or if it's dealing with any external communications
(pipes, network, etc.) that may be subject to timing differences,
there is no reason to expect it to behave deterministically.
> Besides, if the memory is freed before, the csize of this chunk
> should be the same with next chunk's psize.
Not necessarily. If the freed chunk was merged with neighboring free
space, the bytes which were headers and footers at the time of free
need not be headers and footers now. If they were not overwritten,
they'll still have their old values but there's no reason to assume
the old values are consistent at this point.
> And the chunk's next and
> prev pointer should point at <mal+xx>.
Not necessarily; they could point to the bin head at mal+xx or to
other free chunks in the same bin. In the case of two frees in
immediate succession (with no concurrency) you would expect to find
the freed chunk at the start of its bin, but in general that need not
be the case.
> For example, the 3rd case.
> #0 0x0045e320 in a_crash () at src/malloc/malloc.c:465
> #1 free (p=0x7b81e0) at src/malloc/malloc.c:465
> psize csize prev next
> 0x7b81d8: 0x11 0x30 0x4 0x3d0504 <json_object_object_delete>
> 0x7b81e8: 0x3d0268 <json_object_object_to_json_string> 0x0 0x0 0x0
> 0x7b81f8: 0x7b8210 0x0 0x0 0x0
> 0x7b8208: 0x31 0x40 0x60ed30 <mal+56> 0x60ed30 <mal+56>
Of these 4 lines, only the first and last look like it's likely that
they are or were chunk headers. Assuming the 0x30 in the first line is
correct, the second and third lines are just space inside the freed
chunk. But then the fourth line wrongly has the chunk marked as
in-use, and has another free chunk (of size 0x40) adjacent, which is
inconsistent.
In case there is any actual bug on our side, rather than just memory
corruption by the application, can you fill us in on any additional
details, especially whether the process is multithreaded? Knowing that
would determine what sorts of further investigation might or couldn't
be useful.
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.
