From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/12305 Path: news.gmane.org!.POSTED!not-for-mail From: John Reiser Newsgroups: gmane.linux.lib.musl.general Subject: a third bug in musl clone() Date: Tue, 2 Jan 2018 10:24:42 -0800 Message-ID: <3d795d15-4808-6120-e497-d6c367c14952@bitwagon.com> References: <20171223094545.rmx6xtmucyz5xzap@voyager> <72c68934-4445-c83d-7bbc-004953b2f9e9@bitwagon.com> <20171231154926.GG1627@brightrain.aerifal.cx> <20180101195224.tpkl5g5w66rzwzz3@voyager> <5caf910a-dd98-6836-c70f-6a98cf8a9d22@bitwagon.com> <20180102014915.GJ1627@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: blaine.gmane.org 1514917391 10680 195.159.176.226 (2 Jan 2018 18:23:11 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 2 Jan 2018 18:23:11 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 To: musl@lists.openwall.com Original-X-From: musl-return-12321-gllmg-musl=m.gmane.org@lists.openwall.com Tue Jan 02 19:23:07 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 1eWRDE-0001sU-JA for gllmg-musl@m.gmane.org; Tue, 02 Jan 2018 19:22:56 +0100 Original-Received: (qmail 32538 invoked by uid 550); 2 Jan 2018 18:24:57 -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 32500 invoked from network); 2 Jan 2018 18:24:57 -0000 In-Reply-To: <20180102014915.GJ1627@brightrain.aerifal.cx> Content-Language: en-US Xref: news.gmane.org gmane.linux.lib.musl.general:12305 Archived-At: In addition to the bugs in __clone for i386 with %gs and stack alignment in the new thread, there is a third bug in musl's implementation of clone(). clone() takes optional arguments that need not be present, yet musl/src/linux/clone.c fetches them anyway. This can cause SIGSEGV. ===== musl/src/linux/clone.c excerpts int clone(int (*func)(void *), void *stack, int flags, void *arg, ...) { [[snip]] va_start(ap, arg); ptid = va_arg(ap, pid_t *); tls = va_arg(ap, void *); ctid = va_arg(ap, pid_t *); va_end(ap); return __syscall_ret(__clone(func, stack, flags, arg, ptid, tls, ctid)); } ===== The presence of ptid, tls, and ctid is indicated by bits in 'flags': CLONE_PARENT_SETTID, CLONE_SETTLS, CLONE_CHILD_SETTID/CLONE_CHILD_CLEARTID. If none of those bits are set, then it could be that none of the variable arguments are present; therefore none of them should be fetched, and 0 (NULL) should be passed to __clone() for each of ptid, tls, ctid. [The meaning is unclear if any omitted argument is followed by an argument that is flagged as present. Should the implementation call the corresponding va_arg(), or skip over it?] How SIGSEGV can be generated: It is valid for &arg to be the address of the last word on a hardware page: 0x...ffc on a 32-bit CPU with 4KiB pages, with the following page unmapped. &func would be 16-byte aligned at 0x...ff0. Any one of the va_arg() calls would attempt to fetch from the next page at address 0x...000 or greater, which will generate SIGSEGV. If the implementer of clone() actually thought about this then it is MANDATORY to insert a code comment about the situation. Such as: /* Always fetch ptid,tls,ctid even though the official standard * says that they are va_arg. The standard says that only * to allow compilation of [old] calls that omit un-flagged * trailing arguments. In practice it is highly unreasonable * to require conditional fetching; even the meaning is unclear. * In the extremely unlikely case that &arg is near a "hole" * in the address space, then we will suffer SIGSEGV. */ --