From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/13411 Path: news.gmane.org!.POSTED!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: printf family handling of INT_MAX +1 tested on aarch64 Date: Wed, 7 Nov 2018 21:04:45 -0500 Message-ID: <20181108020445.GZ5150@brightrain.aerifal.cx> References: <20181107203121.GT5150@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: blaine.gmane.org 1541642575 25533 195.159.176.226 (8 Nov 2018 02:02:55 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 8 Nov 2018 02:02:55 +0000 (UTC) User-Agent: Mutt/1.5.21 (2010-09-15) To: musl@lists.openwall.com Original-X-From: musl-return-13427-gllmg-musl=m.gmane.org@lists.openwall.com Thu Nov 08 03:02:51 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 1gKZej-0006Td-Ge for gllmg-musl@m.gmane.org; Thu, 08 Nov 2018 03:02:49 +0100 Original-Received: (qmail 18113 invoked by uid 550); 8 Nov 2018 02:04:58 -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 18095 invoked from network); 8 Nov 2018 02:04:57 -0000 Content-Disposition: inline In-Reply-To: Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:13411 Archived-At: On Wed, Nov 07, 2018 at 02:54:02PM -0600, CM Graff wrote: > RIch, > It just produces a segfault on debian aarch64 in my test case. Whereas > INTMAX + 2 does not. So I thought it worth reporting. > > graff@hlib-debian-arm:~/hlibc-test/tests-emperical/musl$ > ../usr/bin/musl-gcc ../printf_overflow.c > graff@hlib-debian-arm:~/hlibc-test/tests-emperical/musl$ > ../usr/bin/musl-gcc -static ../printf_overflow.c > graff@hlib-debian-arm:~/hlibc-test/tests-emperical/musl$ ./a.out > logfile > Segmentation fault > graff@hlib-debian-arm:~/hlibc-test/tests-emperical/musl$ uname -a > Linux hlib-debian-arm 4.9.0-8-arm64 #1 SMP Debian 4.9.110-3+deb9u6 > (2018-10-08) aarch64 GNU/Linux > graff@hlib-debian-arm:~/hlibc-test/tests-emperical/musl$ > > I can supply access to the 96 core 124 GB RAM aarch64 debian test box > if it would help reproduce the segfault. Just email me a public key if > you want access. The failure has nothing to do with printf. You're calling malloc(i) then writing to s[i], which is one past the end of the allocated buffer. I failed to notice this because you're only writing i-1 A's to the buffer, and there already happens to be a nul byte at s[i-1] to terminate them. Actually the crash has nothing to do with aarch64 vs x86_64 but rather static vs dynamic linking. With dynamic linking, full malloc is used and there happens to be padding space at the end of the allocation because there was a header at the beginning and it has to be rounded up to whole pages. But with static linking, simple_malloc (a bump allocator) was used, and there are exactly i bytes in the allocation. Fix the s[i]=0 to be s[i-1]=0 instead and the test works as expected. And please, when reporting crashes like this, at least try to identify where the crash is occurring (e.g. with gdb or even just some trivial printf debugging). Rich