From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/13529 Path: news.gmane.org!.POSTED!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: aio_cancel segmentation fault for in progress write requests Date: Fri, 7 Dec 2018 13:26:50 -0500 Message-ID: <20181207182650.GF23599@brightrain.aerifal.cx> References: <20181207154419.GD23599@brightrain.aerifal.cx> <20181207165217.GE23599@brightrain.aerifal.cx> <54b4d253-1660-3207-5d59-f23f1c25b2b9@adelielinux.org> 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 1544207100 25706 195.159.176.226 (7 Dec 2018 18:25:00 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 7 Dec 2018 18:25:00 +0000 (UTC) User-Agent: Mutt/1.5.21 (2010-09-15) To: musl@lists.openwall.com Original-X-From: musl-return-13545-gllmg-musl=m.gmane.org@lists.openwall.com Fri Dec 07 19:24:56 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 1gVKo3-0006XY-8B for gllmg-musl@m.gmane.org; Fri, 07 Dec 2018 19:24:55 +0100 Original-Received: (qmail 28355 invoked by uid 550); 7 Dec 2018 18:27:04 -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 28310 invoked from network); 7 Dec 2018 18:27:03 -0000 Content-Disposition: inline In-Reply-To: <54b4d253-1660-3207-5d59-f23f1c25b2b9@adelielinux.org> Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:13529 Archived-At: On Fri, Dec 07, 2018 at 11:31:01AM -0600, A. Wilcox wrote: > awilcox on gwyn [pts/7 Fri 7 11:29] ~: ./aioWrite > zsh: segmentation fault ./aioWrite > awilcox on gwyn [pts/7 Fri 7 11:29] ~: ./aioWrite > zsh: segmentation fault ./aioWrite > awilcox on gwyn [pts/7 Fri 7 11:29] ~: ./aioWrite > zsh: segmentation fault ./aioWrite > awilcox on gwyn [pts/7 Fri 7 11:29] ~: ./aioWrite > zsh: segmentation fault ./aioWrite > awilcox on gwyn [pts/7 Fri 7 11:29] ~: ./aioWrite > zsh: segmentation fault ./aioWrite > awilcox on gwyn [pts/7 Fri 7 11:29] ~: gdb aioWrite > GNU gdb (GDB) 8.2 > Copyright (C) 2018 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later > > This is free software: you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law. > Type "show copying" and "show warranty" for details. > This GDB was configured as "powerpc64-foxkit-linux-musl". > Type "show configuration" for configuration details. > For bug reporting instructions, please see: > . > Find the GDB manual and other documentation resources online at: > . > > For help, type "help". > Type "apropos word" to search for commands related to "word"... > Reading symbols from aioWrite...done. > (gdb) run > Starting program: /home/awilcox/aioWrite > [New LWP 60165] > [LWP 60165 exited] > aio_write/1-1.c cancelationStatus : 2 > Test PASSED > [Inferior 1 (process 60162) exited normally] > (gdb) quit > > > Well, that's pretty interesting. > > > awilcox on gwyn [pts/7 Fri 7 11:29] ~: uname -a > Linux gwyn 4.14.76-mc11-easy-p8 #1 SMP Sat Nov 17 04:52:54 UTC 2018 > ppc64 GNU/Linux > awilcox on gwyn [pts/7 Fri 7 11:30] ~: /lib/ld-musl-powerpc64.so.1 > musl libc (powerpc64) > Version 1.1.20 > Dynamic Program Loader > Usage: /lib/ld-musl-powerpc64.so.1 [options] [--] pathname [args] > > > Maybe this is a bug that has been fixed on master? I don't think so. I'm concerned that it's a stack overflow, and that somehow the kernel folks have managed to break the MINSIGSTKSZ ABI. AIO threads use a PTHREAD_STACK_MIN-sized stack with no guard page (because they don't run any application code, just a tiny stub function) but this could overflow in kernelspace (and either crash or clobber memory depending on memory layout and presence/absence of ASLR) if the kernel is making a signal frame that's too big. Note that this would have to be nearly twice MINSIGSTKSZ (on x86 at least) due to rounding up to whole pages, so if the kernel is misbehaving here it's *badly* misbehaving... Rich