Bug 434714 - Artificial ELF executable does not execute (gets Killed)
Artificial ELF executable does not execute (gets Killed)
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
rawhide
x86_64 Linux
low Severity low
: ---
: ---
Assigned To: Kernel Maintainer List
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-02-24 16:40 EST by Jan Kratochvil
Modified: 2008-04-27 16:44 EDT (History)
1 user (show)

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


Attachments (Terms of Use)
bzip2 of the ELF binary getting Killed (231 bytes, application/octet-stream)
2008-02-24 16:40 EST, Jan Kratochvil
no flags Details

  None (edit)
Description Jan Kratochvil 2008-02-24 16:40:30 EST
Description of problem:
Found I can create an artifical executable working on upstrea and F8 but getting
`Killed' on Rawhide.

Version-Release number of selected component (if applicable):
kernel-2.6.25-0.65.rc2.git7.fc9.x86_64

How reproducible:
Always.

Steps to Reproduce:
echo -e '.globl _start\n_start: movq $231,%rax\nsyscall' | as -o trapkill.o; ld
-o trapkill trapkill.o --script=/dev/null; ./trapkill; echo $?

Actual results:
Killed
137

Expected results:
0

Additional info:
Have not seen a real world executable failing this way, only this artifical one.

Found on the GDB testsuite run on a testcase of mine:
-PASS: gdb.dwarf2/dw2-ranges.exp: run
-PASS: gdb.dwarf2/dw2-ranges.exp: backtrace
+FAIL: gdb.dwarf2/dw2-ranges.exp: run
+FAIL: gdb.dwarf2/dw2-ranges.exp: backtrace

It works fine on:
kernel-2.6.23.14-107.fc8.x86_64 (Fedora 8)
kernel-vanilla-2.6.21-1.3190.fc7.x86_64 (some older custom build)
vanilla 2.6.22-rc4-git7.x86_64 (upstream)
Comment 1 Jan Kratochvil 2008-02-24 16:40:30 EST
Created attachment 295749 [details]
bzip2 of the ELF binary getting Killed
Comment 2 Jan Kratochvil 2008-02-24 16:46:58 EST
Convenient ELF dump (of the executable stripped with the same reproducibility):

ELF Header:
  Magic:   7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00
  Class:                             ELF64
  Data:                              2's complement, little endian
  Ident Version:                     1 (current)
  OS/ABI:                            UNIX - System V
  ABI Version:                       0
  Type:                              EXEC (Executable file)
  Machine:                           AMD x86-64
  Version:                           1 (current)
  Entry point address:               0
  Start of program headers:          64 (bytes into file)
  Start of section headers:          2097184 (bytes into file)
  Flags:
  Size of this header:               64 (bytes)
  Size of program header entries:    56 (bytes)
  Number of program headers entries: 1
  Size of section header entries:    64 (bytes)
  Number of section headers entries: 3
  Section header string table index: 2

Section Headers:
[Nr] Name                 Type         Addr             Off      Size     ES
Flags Lk Inf Al
[ 0]                      NULL         0000000000000000 00000000 00000000  0   
    0   0  0
[ 1] .text                PROGBITS     0000000000000000 00200000 00000009  0 AX
    0   0  4
[ 2] .shstrtab            STRTAB       0000000000000000 00200009 00000011  0   
    0   0  1

Program Headers:
  Type           Offset   VirtAddr           PhysAddr           FileSiz  MemSiz
  Flg Align
  LOAD           0x200000 0x0000000000000000 0x0000000000000000 0x000009
0x000009 R E 0x200000

 Section to Segment mapping:
  Segment Sections...
   00      [RO: .text]
Comment 3 Jan Kratochvil 2008-02-24 18:23:39 EST
Fix of the uninitialized exit code - but everything is still the same:

Steps to Reproduce:
echo -e '.globl _start\n_start: movq $231,%rax\nmovq $42,%rdi\nsyscall' | as -o
trapkill.o; ld -o trapkill trapkill.o --script=/dev/null; ./trapkill; echo $?

Actual results:
Killed
137

Expected results:
42
Comment 4 Roland McGrath 2008-02-26 16:25:26 EST
Not reproduced on my upstream tip build.  Maybe an exec-shield breakage?
Comment 5 Jan Kratochvil 2008-02-26 16:45:52 EST
(In reply to comment #4)
> Not reproduced on my upstream tip build.  Maybe an exec-shield breakage?

Just tried it is still broken (on kernel-2.6.25-0.65.rc2.git7.fc9.x86_64) with:
  echo 0 >/proc/sys/kernel/exec-shield
Comment 6 Chuck Ebbert 2008-04-26 21:01:31 EDT
echo "0" >/proc/sys/vm/mmap_min_addr

That should fix it -- at least on F8 changing that from 0 to 32768 made it fail.
(The executable code starts at 0.)

Comment 7 Roland McGrath 2008-04-27 16:31:21 EDT
Yup, I think this is pretty much expected behavior.
i.e. an ET_EXEC with a p_vaddr at 0 is asking for a mmap that it is often
security policy to refuse.  Unfortunately there really isn't much better than
SIGKILL death that you can expect for this.
Comment 8 Jan Kratochvil 2008-04-27 16:44:40 EDT
OK, thanks for the explanation.
(The GDB testcase fortunately already no longer uses this 0-based executable.)

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