Hi,

Python ctypes module creates a 'rwx' memory mapping (defined in malloc_closure.c) which causes python to crash when running under grsecurity enabled kernel and could also have a negative security impact. 

Is there any specific need for the mmap call to create an executable mapping or can it be safely removed? 

Please refer here for more information and proposed patch:
http://bugs.gentoo.org/show_bug.cgi?id=329499

The actual mmap call:
item = (ITEM *)mmap(NULL,
                            count * sizeof(ITEM),
                            PROT_READ | PROT_WRITE | PROT_EXEC,
                            MAP_PRIVATE | MAP_ANONYMOUS,
                            -1,
                            0);

There has been further investigation done by Gentoo users and work towards python handling this error gracefully rather than segfaulting. It seems that dereference at Py_XDECREF(self->restype); (line 23 of Modules/_ctypes/callbacks.c) causes the segfault.

Thanks.

segfault info:
# grep 65725f6b /var/log/grsec.log
#
Jul 27 00:58:53 [kernel] grsec: Segmentation fault occurred at 65725f6b in /home/root/syschroot/usr/bin/python2.6[python2.6:23877] uid/euid:0/0 gid/egid:0/0, parent /home/root/syschroot/bin/bash[bash:25516] uid/euid:0/0 gid/egid:0/0

Note that the removing of PROT_EXEC flag doesn't break any ctypes test.

Does the patch from issue #5504 work for you?

Arfrever, do you mean this patch?
http://bugs.python.org/file13897/issue5504-linux.patch

It does not cleanly apply to Gentoo's 2.6.5-r3 ebuild, neither it does apply to 2.6.5, 2.7 or 3.2.1 releases from the Python website.

Which python release/branch should it work with?

Output below:
Python-2.6.5 # patch -p0 < ../issue5504-linux.patch
patching file setup.py
Hunk #1 succeeded at 1744 (offset 23 lines).
patching file Modules/_ctypes/malloc_closure.c
Reversed (or previously applied) patch detected!  Assume -R? [n] n
Apply anyway? [n] y
Hunk #1 FAILED at 1.
File Modules/_ctypes/malloc_closure.c is not empty after patch, as expected
1 out of 1 hunk FAILED -- saving rejects to file Modules/_ctypes/malloc_closure.c.rej
patching file Modules/_ctypes/_ctypes.c
Hunk #1 succeeded at 3443 (offset 3 lines).
patching file Modules/_ctypes/libffi/fficonfig.py.in
patching file Modules/_ctypes/libffi/src/closures.c
patching file Modules/_ctypes/libffi/src/dlmalloc.c
patching file Modules/_ctypes/ctypes.h
patching file Modules/_ctypes/callbacks.c
Hunk #1 FAILED at 21.
Hunk #3 FAILED at 403.
Hunk #4 succeeded at 451 (offset 1 line).
2 out of 4 hunks FAILED -- saving rejects to file Modules/_ctypes/callbacks.c.rej

src # cd Python-2.7
Python-2.7 # patch -p0 < ../issue5504-linux.patch
patching file setup.py
Hunk #1 succeeded at 1865 (offset 144 lines).
patching file Modules/_ctypes/malloc_closure.c
Reversed (or previously applied) patch detected!  Assume -R? [n]
Apply anyway? [n] y
Hunk #1 FAILED at 1.
File Modules/_ctypes/malloc_closure.c is not empty after patch, as expected
1 out of 1 hunk FAILED -- saving rejects to file Modules/_ctypes/malloc_closure.c.rej
patching file Modules/_ctypes/_ctypes.c
Hunk #1 FAILED at 3440.
1 out of 1 hunk FAILED -- saving rejects to file Modules/_ctypes/_ctypes.c.rej
patching file Modules/_ctypes/libffi/fficonfig.py.in
patching file Modules/_ctypes/libffi/src/closures.c
patching file Modules/_ctypes/libffi/src/dlmalloc.c
patching file Modules/_ctypes/ctypes.h
Hunk #1 FAILED at 95.
1 out of 1 hunk FAILED -- saving rejects to file Modules/_ctypes/ctypes.h.rej
patching file Modules/_ctypes/callbacks.c
Hunk #1 FAILED at 21.
Hunk #2 FAILED at 373.
Hunk #3 FAILED at 403.
Hunk #4 FAILED at 450.
4 out of 4 hunks FAILED -- saving rejects to file Modules/_ctypes/callbacks.c.rej

Python-2.7 # cd ..
src # cd Python-3.1.2
Python-3.1.2 # patch -p0 < ../issue5504-linux.patch 
patching file setup.py
Hunk #1 succeeded at 1513 (offset -208 lines).
patching file Modules/_ctypes/malloc_closure.c
Reversed (or previously applied) patch detected!  Assume -R? [n] y
patching file Modules/_ctypes/_ctypes.c
Hunk #1 succeeded at 3367 (offset -73 lines).
patching file Modules/_ctypes/libffi/fficonfig.py.in
patching file Modules/_ctypes/libffi/src/closures.c
patching file Modules/_ctypes/libffi/src/dlmalloc.c
patching file Modules/_ctypes/ctypes.h
Hunk #1 succeeded at 54 (offset -41 lines).
patching file Modules/_ctypes/callbacks.c
Hunk #1 FAILED at 21.
Hunk #2 succeeded at 370 (offset -3 lines).
Hunk #3 succeeded at 401 with fuzz 2 (offset -2 lines).
Hunk #4 succeeded at 448 (offset -2 lines).
1 out of 4 hunks FAILED -- saving rejects to file Modules/_ctypes/callbacks.c.rej

Yes, the aforementioned patch does the job when applied manually with some tweaking and importing ctypes does not result in a MemoryError anymore. Tested with Python-2.7 and Python-3.1.2.

This is a duplicate of #5504, according to Arfrever