Bug 247261 - segmentation fault in load_elf_binary()
Summary: segmentation fault in load_elf_binary()
Status: CLOSED DUPLICATE of bug 247169
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: kernel-xen   
(Show other bugs)
Version: 5.0
Hardware: All Linux
Target Milestone: ---
: ---
Assignee: Rik van Riel
QA Contact: Brian Brock
Depends On:
TreeView+ depends on / blocked
Reported: 2007-07-06 13:33 UTC by Ian Campbell
Modified: 2007-11-30 22:07 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-07-06 16:23:34 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
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 13:33 UTC, Ian Campbell
no flags Details

Description Ian Campbell 2007-07-06 13:33:44 UTC
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

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 13:33:44 UTC
Created attachment 158657 [details]
Patch which resolves the issue

Comment 2 Rik van Riel 2007-07-06 16:23:34 UTC

*** 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.