linux-kernel - musl-libc/MIPS: detached thread exit broken since kernel commit 46e12c07b

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <55837978.7020801@universe-factory.net>
Date:	Fri, 19 Jun 2015 04:07:52 +0200
From:	Matthias Schiffer <mschiffer@...verse-factory.net>
To:	musl@...ts.openwall.com, linux-mips@...ux-mips.org,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Ralf Baechle <ralf@...ux-mips.org>
Subject: musl-libc/MIPS: detached thread exit broken since kernel commit
 46e12c07b

Hi,
I've come across the issue that applications with detached threads
(using pthread_detach or a pthread_attr_t with
pthread_attr_setdetachstate) will segfault using musl-libc on MIPS as
soon as the detached thread exits. As far as I can tell, the underlying
issue is the following:

To clean up after itself, the finishing thread will call __unmapself,
which will unmap the thread's own stack and call the exit syscall
directly after that, without accessing the now unmapped stack.

This worked fine in 2012, when pthread support for MIPS was implemented
in musl. It seems to have been broken by kernel commit 46e12c07b "MIPS:
O32 / 32-bit: Always copy 4 stack arguments." (also in 2012) which made
the kernel unconditionally copy 4 stack arguments, even when the syscall
doesn't even use the arguments.

I guess this would be reasonably easy to fix up in musl, but let's also
get the linux-mips people's opinions, as that commit obviously broke the
kernel ABI...

Download attachment "signature.asc" of type "application/pgp-signature" (820 bytes)