Bug 434714

Summary: Artificial ELF executable does not execute (gets Killed)
Product: [Fedora] Fedora Reporter: Jan Kratochvil <jan.kratochvil>
Component: kernelAssignee: Kernel Maintainer List <kernel-maint>
Status: CLOSED NOTABUG QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: low Docs Contact:
Priority: low    
Version: rawhideCC: roland
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-04-27 20:44:40 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
bzip2 of the ELF binary getting Killed none

Description Jan Kratochvil 2008-02-24 21:40:30 UTC
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 21:40:30 UTC
Created attachment 295749 [details]
bzip2 of the ELF binary getting Killed

Comment 2 Jan Kratochvil 2008-02-24 21:46:58 UTC
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 23:23:39 UTC
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 21:25:26 UTC
Not reproduced on my upstream tip build.  Maybe an exec-shield breakage?

Comment 5 Jan Kratochvil 2008-02-26 21:45:52 UTC
(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-27 01:01:31 UTC
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 20:31:21 UTC
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 20:44:40 UTC
OK, thanks for the explanation.
(The GDB testcase fortunately already no longer uses this 0-based executable.)