Bug 120468 - binfmt_elf bad code for exec_shield
Summary: binfmt_elf bad code for exec_shield
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel   
(Show other bugs)
Version: rawhide
Hardware: i386 Linux
medium
medium
Target Milestone: ---
Assignee: Arjan van de Ven
QA Contact: Brian Brock
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2004-04-09 01:03 UTC by John Reiser
Modified: 2007-11-30 22:10 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-04-16 08:58:57 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
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-09 01:06 UTC, John Reiser
no flags Details | Diff

Description John Reiser 2004-04-09 01:03:37 UTC
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):
kernel-2.6.5-1.308

How reproducible:
Always

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

Actual Results:  Notice mixture of EXSTACK_*_X symbols and bare
constants 0,1:
g/executable_stack/p
        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-09 01:06:43 UTC
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 07:27:06 UTC
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 14:16:17 UTC
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 14:18:14 UTC
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.