From: Mike Hearn <mike@navi.cx>
To: linux-kernel@vger.kernel.org
Subject: Potential bug in fs/binfmt_elf.c?
Date: Fri, 05 Mar 2004 17:38:01 +0000 [thread overview]
Message-ID: <1078508281.3065.33.camel@linux.littlegreen> (raw)
Hi,
I believe there is a problem in fs/binfmt_elf.c, around line 700 (kernel
2.6.1)
When mapping a nobits PT_LOAD segment with a memsize > filesize, the
kernel calls set_brk (which in turns calls do_brk) to map and clear the
area, but this discards access permissons on the mapping leading to rwx
protection. This causes a load failure on systems where the VM cannot
reserve swap space for the segment, unless overcommit is active (on many
systems it's not on by default).
I don't know this code well, but it seems that this discarding of access
permissions on the unlikely codepath is incorrect. I filed bug #2255 [1]
on it.
Could somebody who understands the ELF loading code please check to see
if this is a bug, and if so produce a patch?
The ability to define a new (large) ELF section which isn't backed by
swap space nor disk space and that will be mapped to a specific VMA
range is needed by Wine to reserve the PE load area.
Currently the fact that the section is always mapped rwx despite being
marked read-only in the binary prevents us from using this as a solution
to the problems caused by exec-shield/prelink, meaning the only solution
is to bootstrap the ELF interpreter ourselves from a statically linked
binary. Clearly we'd rather not do that.
Thanks to pageexec@freemail.hu for bringing the matter to my attention.
Your assistance is appreciated,
thanks -mike
[1] http://bugzilla.kernel.org/show_bug.cgi?id=2255
next reply other threads:[~2004-03-05 17:33 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-03-05 17:38 Mike Hearn [this message]
2004-03-05 18:28 ` Potential bug in fs/binfmt_elf.c? John Reiser
2004-03-06 18:46 ` Ulrich Drepper
2004-03-06 21:10 ` Mike Hearn
2004-03-07 6:11 ` Ulrich Drepper
2004-03-07 9:58 ` Mike Hearn
2004-03-07 10:46 ` Ulrich Drepper
2004-03-07 11:53 ` Mike Hearn
2004-03-07 21:32 ` Ulrich Drepper
2004-03-07 23:55 ` Eric W. Biederman
2004-03-08 5:57 ` John Reiser
2004-03-08 8:06 ` Jakub Jelinek
2004-03-11 6:17 ` [PATCH] binfmt_elf.c allow .bss with no access (p---) John Reiser
2004-03-11 14:23 ` Mike Hearn
2004-03-11 19:18 ` John Reiser
2004-03-12 16:42 ` Mike Hearn
[not found] ` <20040412185317.79ac7d7d.akpm@osdl.org>
2004-04-13 17:33 ` John Reiser
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1078508281.3065.33.camel@linux.littlegreen \
--to=mike@navi.cx \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.