GNU bug report logs - #11398
24.0.95; Segfault in unexec on Linux 3.3* with grsecurity/PaX

Previous Next

Full log

View this message in rfc822 format

From: Ulrich Mueller <ulm <at> gentoo.org>
To: 11398 <at> debbugs.gnu.org
Cc: Jan Djärv <jan.h.d <at> swipnet.se>
Subject: bug#11398: 24.0.95; Segfault in unexec on Linux 3.3* with grsecurity/PaX
Date: Thu, 3 May 2012 11:12:00 +0200

Forwarding downstream bug <https://bugs.gentoo.org/411439>.

Emacs 23.4 and 24.0.95 both fail to build on a Gentoo system with a
sys-kernel/hardened-sources-3.3* kernel, i.e. Linux 3.3* with the
grsecurity/PaX patches from <http://grsecurity.net/>
(e.g., grsecurity-2.9-3.3.4-201204272006.patch).

   Dumping under the name emacs
   **************************************************
   Warning: Your system has a gap between BSS and the
   heap (15045480 bytes).  This usually means that exec-shield
   or something similar is in effect.  The dump may
   fail because of this.  See the section about
   exec-shield in etc/PROBLEMS for more information.
   **************************************************
   make[1]: *** [bootstrap-emacs] Segmentation fault
   make[1]: Leaving directory `/var/tmp/portage/app-editors/emacs-23.4-r1/work/emacs-23.4/src'
   make: *** [src] Error 2

Since it still could be successfully built with hardened-sources-3.2*,
we had first reported this problem to grsecurity/PaX upstream.
However, they claim that it is due to a bug in Emacs' unexec code.

Quoting from <https://bugs.gentoo.org/show_bug.cgi?id=411439#c13> and
following comments:

| i've debugged the problem and it's a bug in emacs. it wants to create
| a memory dump of its address space without actually looking at what
| memory ranges are available with what access rights. due to recentish
| changes in PaX the gap between the end of the main executable's data
| section and the start of the brk heap is mapped with PROT_NONE rights,
| so no access is allowed and this is where emacs fails.

| ADDR_NO_RANDOMIZE was added as a workaround to fix userland bugs
| like what emacs has (the first bug is about assuming a particular
| address space layout that no standard has ever guaranteed, the
| second bug is that emacs doesn't use the kernel provided interface
| to discover its own address space layout).

| [...] fundamentally a bug in emacs's memory dumper code, the proper
| fix should be in there.

Could GNU Emacs upstream comment on this, please?

Ulrich

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.