Bug 120468 - binfmt_elf bad code for exec_shield
binfmt_elf bad code for exec_shield
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Arjan van de Ven
Brian Brock
Depends On:
  Show dependency treegraph
Reported: 2004-04-08 21:03 EDT by John Reiser
Modified: 2007-11-30 17:10 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-04-16 04:58:57 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
proposed patch implements expected behavior of exec_shield in load_elf_binary() (2.08 KB, patch)
2004-04-08 21:06 EDT, John Reiser
no flags Details | Diff

  None (edit)
Description John Reiser 2004-04-08 21:03:37 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040312

Description of problem:
The code for load_elf_binary() in fs/binfmt_elf.c does not implement
exec_shield according to the documentation.  The code also uses bare
nunmerical constants instead of the conventional symbols.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Inspect code at fs/binfmt_elf.c:648,38.

Actual Results:  Notice mixture of EXSTACK_*_X symbols and bare
constants 0,1:
        int executable_stack = EXSTACK_DEFAULT;
                                executable_stack = EXSTACK_ENABLE_X;
                                executable_stack = EXSTACK_DISABLE_X;
        executable_stack = 1;
                                        executable_stack = 0;
                executable_stack = 0;

Notice that the "switch (exec_shield)" at line 665 follows the
PT_GNU_STACK check at lines 654-659.  This means that exec_shield
overrides, where as the documentation says that exec_shield equal to 2
or 3 implies that the application PT_GNU_STACK overrides.

Expected Results:  Manipulation of variable 'executable_stack' should
use EXSTACK_*_X symbols instead of bare numeric constants. 
exec_shield should defer to application when exec_shield is 2 or 3.

Additional info:
Comment 1 John Reiser 2004-04-08 21:06:43 EDT
Created attachment 99260 [details]
proposed patch implements expected behavior of exec_shield in load_elf_binary()

Also notice that the patch implementation of exec_shield has made the default
"executable_stack = EXSTACK_DEFAULT;" irrelevant.
Comment 2 Arjan van de Ven 2004-04-09 03:27:06 EDT
ehhh documentation ?
the =2 and =3 option probably should just go away btw.....
(but thanks for the patch and reporting this)
Comment 3 John Reiser 2004-04-09 10:16:17 EDT
Original ocumentation with 4 values as above:
http://lwn.net/Articles/31032/  which quotes the May 2003 announcement
to LKML by Ingo.

FC1 documentation with 3 values as in 2.6.5-1.308: (0:off; 1: enabled
as per PT_GNU_STACK; 2: forced on):
/usr/share/doc/fedora-release-1/RELEASE-NOTES-i386 and .html.

FC2 documentation: not listed!  Only reference to "exec?shield" is in
/usr/share/doc/gcc34-3.4.0/ChangeLog which refers to the -randomize.

So, part of the problem is that documenation is missing, and there are
insufficient comments in the code to explain the intent of the values.

I will attach another patch conforming to the FC1 documentation, but
still with only 1 instance of the loop that checks PT_GNU_STACK, and
this time also uses that loop for personality!=PER_LINUX.

[I'm trying to keep my "elfdiet" patches current, and became confused
by the code I saw in load_elf_binary() for 2.6.5-1.308.]

Comment 4 Arjan van de Ven 2004-04-09 10:18:14 EDT
we fixed it in 313 kernel already; available on
people.redhat.com/arjanv/2.6 and tomorrows rawhide rsync

Note You need to log in before you can comment on or make changes to this bug.