Date: Mon, 27 Jan 2020 06:28:57 +0100 From: Markus Wichmann <nullplan@....net> To: musl@...ts.openwall.com Subject: Re: 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 seg > faults sometimes with musl. I managed to reproduce the seg fault via > musl-gcc and Alpine Linux and document it here . Seems to be some kind > 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 report > a .so being loaded by ldd, but on Ubuntu the same binary is reported as > being static? Also, detail that here  too. > >  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
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.