Bug 247261 - segmentation fault in load_elf_binary()
segmentation fault in load_elf_binary()
Status: CLOSED DUPLICATE of bug 247169
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: kernel-xen (Show other bugs)
5.0
All Linux
low Severity low
: ---
: ---
Assigned To: Rik van Riel
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-07-06 09:33 EDT by Ian Campbell
Modified: 2007-11-30 17:07 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-07-06 12:23:34 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)
Patch which resolves the issue (1.19 KB, text/x-patch)
2007-07-06 09:33 EDT, Ian Campbell
no flags Details

  None (edit)
Description Ian Campbell 2007-07-06 09:33:44 EDT
Description of problem:
We have been tripping over a segmentation fault in the ELF binary loader when
loading /lib/ld-linux.so.2.

The kernel is patched (by exec-shield I think) to change load_elf_interp() to
return the offset between the v-addresses in the header and the actual
v-addresses used. It then checks this offset using BAD_ADDR (fs/binfmt_elf.c
line 1015) before adjusting it back into the final address.

We have observed that the offset can fail the BAD_ADDR test even when the final
address would be completely valid. In this case the address is not valid and the
following test for BAD_ADDR (line 1021) segv's the process.

For example vaddr in the ELF header == 0x7cb000 and map_addr == 0x7ca000 gives
load_addr == 0xfffff000 which is returned from load_elf_interp() and fails the
BAD_ADDR check.

The attached patch returns the old semantics to load_elf_interp() (and matches
load_aout_interp()) by moving the adjustment back to the final address back into
load_elf_interp().

I'm not convinced this bug can be kernel-xen specific but that is where we
observed it hence I've filed against that component.

Version-Release number of selected component (if applicable): 2.6.18-8.1.6.EL

How reproducible:
Quite time consuming. We observed the bug due to sshd re-execing itself for each
connection. A continuous loop of ssh logins from another host was sufficient to
trigger the bug in between 1 and 24 hours or so.
Comment 1 Ian Campbell 2007-07-06 09:33:44 EDT
Created attachment 158657 [details]
Patch which resolves the issue
Comment 2 Rik van Riel 2007-07-06 12:23:34 EDT

*** This bug has been marked as a duplicate of 247169 ***

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