Bug 564734

Summary:	layman segfaults with PAX after installing dev-python/ndg-httpsclient PYTHON_TARGETS="python3_4"
Product:	Gentoo Linux	Reporter:	Martin Väth <martin>
Component:	Hardened	Assignee:	The Gentoo Linux Hardened Team <hardened>
Status:	RESOLVED INVALID
Severity:	normal
Priority:	Normal
Version:	unspecified
Hardware:	All
OS:	Linux
Whiteboard:
Package list:		Runtime testing required:	---

Description Martin Väth 2015-11-02 22:09:29 UTC

layman segfaults (on amd64 and x86 hardened systems with PAX) with

segfault at c ip ... sp ... error 6 in libffi.so.6.0.1

if dev-python/ndg-httpsclient (with only PYTHON_TARGETS="python3_4") is installed. Note that the latter package is pulled in by the new version dev-python/requests-2.8.1 which has just been marked stable on amd64 and x86. (However, the problem occurs also with requests 2.6.0 if only ndg-httpsclient is installed)

The problem disappears when switching PAX to softmode (/proc/sys/kernel/pax/softmode), but no paxmarking of libffi.so.6.0.1 avoided the segfault.
Upgrading to libffi-3.2.1 does not help, either.

Renaming the file
/usr/lib64/python3.4/site-packages/cryptography/hazmat/bindings/_openssl.cpython-34.so
from dev-python/cryptography-1.0.2 helps, but no paxmarking of that file avoids the segfault. Upgrading to cryptography-1.1 does not change anything.

Perhaps there is a relation with bug 457194, especially with comment #30
because an strace ends with

open("/proc/self/status", O_RDONLY)     = 5
fstat(5, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x36040997000
read(5, "Name:\tlayman\nState:\tR (running)\n"..., 1024) = 848
close(5)                                = 0
munmap(0x36040997000, 4096)             = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = -1 EPERM (Operation not permitted)
--- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0xc} --

Comment 1 Magnus Granberg gentoo-dev

2015-11-02 22:22:06 UTC

check that you have emutramp on in the kernel and selected python have pax mark E set.

Comment 2 Martin Väth 2015-11-03 17:15:20 UTC

Thanks a lot! Setting EMUTRAMP in the kernel solved the problem.

So it seems that there was nothing wrong except that now it is the first time that EMUTRAMP is really needed for my gentoo system.

Sorry for the noise.