linux-kernel - Re: [musl] 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-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20150619025032.GR1173@brightrain.aerifal.cx>
Date:	Thu, 18 Jun 2015 22:50:32 -0400
From:	Rich Felker <dalias@...c.org>
To:	Matthias Schiffer <mschiffer@...verse-factory.net>
Cc:	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: Re: [musl] musl-libc/MIPS: detached thread exit broken since kernel
 commit 46e12c07b

On Fri, Jun 19, 2015 at 04:07:52AM +0200, Matthias Schiffer wrote:
> 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...

This is kernel ABI breakage that should be fixed -- people running old
kernel versions with old musl binaries might suffer a regression when
upgrading, and perhaps more importantly the failure mode is just
really bad. But I think we can also work around it on the userspace
side in musl by pointing the stack pointer at some rodata (or even at
pc, e.g. copying $25 to $sp) before making the syscall.

Rich
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/