From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-2.9 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED, RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.2 Received: from mother.openwall.net (mother.openwall.net [195.42.179.200]) by inbox.vuxu.org (OpenSMTPD) with SMTP id 7ef7b376 for ; Mon, 27 Jan 2020 05:29:11 +0000 (UTC) Received: (qmail 16342 invoked by uid 550); 27 Jan 2020 05:29:09 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 16321 invoked from network); 27 Jan 2020 05:29:09 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1580102937; bh=XkzrLFtrftlbRe/wMawP1+7JDO/sG9m9UBYKDmwlHWo=; h=X-UI-Sender-Class:Date:From:To:Subject:References:In-Reply-To; b=DvN0OAXkDpRTk7q3oZXFC3IhF1qb3vnbX76nOlByglxTTuOlS3PIPTm/Y3eJW0h+M qDPHYDTg1iNlnNkUAYG1Y9fSFF2jfbawnd8dL2KNdMYSSLjKR/lK4kEaUnKW2dL8qO y0+65F+GU4ocORp0kZ0P4de55Bp99pWHLI6vuM6s= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Date: Mon, 27 Jan 2020 06:28:57 +0100 From: Markus Wichmann To: musl@lists.openwall.com Message-ID: <20200127052857.GH2020@voyager> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) X-Provags-ID: V03:K1:JJo4tKlS3fIcue4ObvdZvMrGe1joAIMFHuYg/saW9nC49i+hhKR ZzrhutJODjrvNJYJJPQygbWwJEBieWEpoYeF8dvQxq9GesQV/sl/504WUXgXMA6lFfSBiEZ WwlivIgJeQIzF5GGf5nMbzaOaDje2rWxMyRpbbufVfKnjB6qMlhnHQZ79Unn+aw8fCrzcta dZJWeCZOS1wCAnvB6vOXA== X-UI-Out-Filterresults: notjunk:1;V03:K0:+cIuxKWAkXk=:N6HdGedDYq1XyBZnACteIw 72eTbdsYIJp501+UPmwDBHuSPm25BtkES5e5u8+LdBHUEKY/hXe7G9Kho5i4PBDmrqQAQ9k6d YoUHSwjI4z7mbD83290W0hR/QpTCn8Ksd7FbMkNmI5aIl0NyZOe11wBTS+dBez10spdFcq1hl f7023mOwOxg23X3lpnil04OgGssWLXYwdG8eCCpYzlpNaDQT6yOQ8N4IvlfSsGWGTj+uBXbBU o/u8Sd2HfkexZJknr3Ydz5wkGHV0ieawwRtqZ+5sKdwBLlWk7Bv7M/bH65VHwz61bVT78Awyv NqbvH99Dc/OS44/6UBHmjstg7vdpEW9cvDfQlu3mJ3ZohrCaWf5yZOHAU7kvjtd1NEaY12NwU QrUBS7rL3zouL+ouiuuMjhtyv9pbNKgARgyNanj9a224jaWVlKhrBnwe3jelccM6tLeM5SFCN c9kR75jRX6+JUYDHsYoTH1KbkutP5QWo6dvhzxbgWNtAVEHKSWiQhrCC5oGNxMySKsy4Eg+2l FB33Yiim/YSE9duMVTXRB87YKkCN9F69o1YYUwK68RuRoXbbszHrXV4GIMXTJ2Ztw1jRqwUc1 oKAg4W49ZAh2UkvzLh2AdXEcqZx8WvgSAyiPIDOeBs6Q7SXUIbfTbYdlHwCF2AuIDE6A+pN7u M7RldlHZ53KnwZ90lEdq09gGMaNFmx7sESuripwH8E+B9zOrNsraqZyjhVt4hr09AEPSuuNCc kM+EFRGkP/6OukLWUKw47z3PkZEA1lEVJleQu0amgjgOgt+nuinVEbiOPeUev243M+OcyRsNW vBKuN+gv42zYD+uRcs9L4D06CtD+lNG4GSYYKkGC072b7T6iJWMnJg9sGyhMIMDGIiaKrqkEb lKyyWdUFzQF2pVbrmPQKLIv5cCAjgJ6+RwujnzpSIORPlT+4zQC4VBQZ84HsIuN1sLy6xLNJL pSG4qSKu2t3EUvsro+xR9b6oTRtqa7m2iCGWvq7Yvjey1sKUtjlxFZ/5n5j6uNEf1dGVJkkMj LSnmu9jCQSwbLbbzvTpH9K7MGr/zWh3loktIjboV2SNQMp68BihUPmgHAzbSTIGSQFFs9x/6i a26OwUMD7dNmg3Oz5zwEXfPOq5mQ/OetztO87L2w/NWtvSgcJsPHaiDGysZLHOW2tAVAhhVHG j/Hq0f1skt2Iwv+335Xn0IYVwfbdbMLtEv2o2i3K1YWUAeGDAW4FNg9TFkGALXg7ims+8z0SA ce6wo4J6CyQ8ztgPG Content-Transfer-Encoding: quoted-printable Subject: Re: [musl] Bug report: Reproduction of seg fault caused by musl thread creation race condition On Sun, Jan 26, 2020 at 04:33:57PM -0800, Simon wrote: > Hello! I recently had some C code which works normally with glibc but se= g > faults sometimes with musl. I managed to reproduce the seg fault via > musl-gcc and Alpine Linux and document it here [1]. Seems to be some kin= d > of race condition, so hopefully you guys also get a seg fault when you > follow my reproduction steps. Hope this helps and looking forward to any > feedback or helping further if possible, Simon Race condition yes, but in your code. Until pthread_create() has returned, you cannot be certain that it has stored the new thread's ID into my_pthread, yet you access my_pthread from the new thread without synchronization. What I presume is happening, is that the new thread starts executing before the main thread has a chance to perform that store. Glibc implements pthread_create() differently and somehow gets around the problem at least most of the time. Incidentally, that also means you are reading my_pthread from the other thread while it is being written in the main thread. That is a data race, and thus undefined behavior. You could add a mutex or an rwlock around my_pthread, or a barrier after the pthread_create() and before the first access in the new thread. > > P.S. musl newbie question: Why does my binary built on Alpine Linux repo= rt > a .so being loaded by ldd, but on Ubuntu the same binary is reported as > being static? Also, detail that here [1] too. > > [1] https://gist.github.com/simonhf/6d8097f4d6caa572cc42354f494b20ef Not a clue, but I guess that Ubuntu's ldd tries to get around the arbitrary code execution problem with ldd by detecting nonstandard interpreters and refusing to use those. See, ldd has no way of actually telling the entire set of needed shared libraries except to run the dynamic interpreter on the file, but if the executable is malicious, then the interpreter is attacker-controlled and might also be malicious. That used to be a well-known social engineering trick. Just ring up your sysadmin and tell them "Hey man, I have a binary XYZ here that says it needs some shared lib. Can you help me?" Then the sysadmin runs ldd on the binary and the dynamic interpreter runs with sysadmin privileges. What could go wrong? Ciao, Markus