From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/12899 Path: news.gmane.org!.POSTED!not-for-mail From: dalias Newsgroups: gmane.linux.lib.musl.general Subject: Re: =?utf-8?B?5Zue5aSN77yaU0lHU0VH?= =?utf-8?Q?V?= and SIGILL at malloc/free on ARM926 Date: Tue, 5 Jun 2018 01:58:48 -0400 Message-ID: <20180605055848.GB1392@brightrain.aerifal.cx> References: <01af059f-bbab-4f3f-9c45-43f8802999c8.xulu@allwinnertech.com> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: blaine.gmane.org 1528178216 11508 195.159.176.226 (5 Jun 2018 05:56:56 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 5 Jun 2018 05:56:56 +0000 (UTC) User-Agent: Mutt/1.5.21 (2010-09-15) To: musl@lists.openwall.com Original-X-From: musl-return-12915-gllmg-musl=m.gmane.org@lists.openwall.com Tue Jun 05 07:56:52 2018 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.84_2) (envelope-from ) id 1fQ4xg-0002uH-It for gllmg-musl@m.gmane.org; Tue, 05 Jun 2018 07:56:52 +0200 Original-Received: (qmail 23834 invoked by uid 550); 5 Jun 2018 05:59:00 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 23802 invoked from network); 5 Jun 2018 05:59:00 -0000 Content-Disposition: inline In-Reply-To: Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:12899 Archived-At: On Tue, Jun 05, 2018 at 11:24:34AM +0800, 徐露 wrote: > > Mon, 4 Jun 2018 05:41:29 -0400, Rich Felker 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 . 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 > 0x7b81e8: 0x3d0268 0x0 0x0 0x0 > 0x7b81f8: 0x7b8210 0x0 0x0 0x0 > 0x7b8208: 0x31 0x40 0x60ed30 0x60ed30 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