From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/11764 Path: news.gmane.org!.POSTED!not-for-mail From: felix.winkelmann@bevuta.com Newsgroups: gmane.linux.lib.musl.general Subject: possible bug in setjmp implementation for ppc64 Date: Mon, 31 Jul 2017 22:06:51 +0200 Message-ID: <1501520360.0.593167188853569@go.bunnymail.go> 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: quoted-printable X-Trace: blaine.gmane.org 1501532716 9676 195.159.176.226 (31 Jul 2017 20:25:16 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 31 Jul 2017 20:25:16 +0000 (UTC) Cc: peter@more-magic.net To: musl@lists.openwall.com Original-X-From: musl-return-11777-gllmg-musl=m.gmane.org@lists.openwall.com Mon Jul 31 22:25:01 2017 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 1dcHFL-0001fA-5U for gllmg-musl@m.gmane.org; Mon, 31 Jul 2017 22:24:59 +0200 Original-Received: (qmail 9730 invoked by uid 550); 31 Jul 2017 20:25:03 -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 26269 invoked from network); 31 Jul 2017 20:07:06 -0000 Xref: news.gmane.org gmane.linux.lib.musl.general:11764 Archived-At: Hi! I think I may have come across a bug in musl on PPC64(le), and the folks on the #musl IRC channel directed me here. I'm not totally sure whether the problem is caused by a my misunderstanding of C library functions or whether it is a plain bug in the musl implementation of setjmp(3). In out project[1] we use setjmp to establish a global trampoline and allocate small objects on the stack using alloca (see [2] for more information about the compiliation strategy used). I was able to reduce the code that crashes to the following: --- #include #include #include #include #include jmp_buf jb; int foo =3D 99; int c =3D 0; void bar() { c++; longjmp(jb, 1); } int main() { setjmp(jb); char *p =3D alloca(256); memset(p, 0, 256); printf("%d\n", foo); if(c < 10) bar(); exit(0); } --- When executing the longjmp, the code that restores $r2 (TOC) after the call to setjmp reads invalid data, because the memset apparently clobbered the stack frame - i.e. the pointer returned be alloca points into a part of the stack frame that is still in use. I tried this on arm, x86_64 and ppc64 with glibc and it seems to work fine, but crashes when linked with musl (running Alpine Linux on a VM) If you need more information, please feel free to ask. You can also keep me CC'd, since I'd be interested in knowing more about the details. felix [1] http://www.call-cc.org [2] http://home.pipeline.com/~hbaker1/CheneyMTA.html