From: Willy Tarreau <w@1wt.eu>
To: Ernie Petrides <petrides@redhat.com>
Cc: Marcelo Tosatti <marcelo@kvack.org>,
Solar Designer <solar@openwall.com>,
Chuck Ebbert <76306.1226@compuserve.com>,
Andrew Morton <akpm@osdl.org>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] binfmt_elf.c : the BAD_ADDR macro again
Date: Tue, 22 Aug 2006 06:36:43 +0200 [thread overview]
Message-ID: <20060822043642.GB9489@1wt.eu> (raw)
In-Reply-To: <200608212336.k7LNa1E8008716@pasta.boston.redhat.com>
On Mon, Aug 21, 2006 at 07:36:01PM -0400, Ernie Petrides wrote:
> On Monday, 21-Aug-2006 at 23:11 +0200, Willy Tarreau wrote:
>
> > > > [...] But before this, I'd like to get comments from
> > > > the people who discussed the subject recently.
> > >
> > > Thus, I think that both 2.4.33 and 2.6.<latest> are okay without any
> > > further changes.
> >
> > At least 2.4 needs the fix to use the correct BAD_ADDR (which is not
> > OK in 2.4.33 yet).
>
> Ah, right. (Sorry, I was verifying the change in a RHEL3 tree.)
>
> In that case, I support your patch as posted. But the whole point of
> that investigation was to fix an exec() vulnerability with a bad ELF
> entry address. This is addressed in the final hunk of the 2.4.33-based
> patch below, which includes the changes that you previously posted.
>
> Cheers. -ernie
Thanks Ernie.
However, I will just comment the printk out instead of removing it
for now. I've backported the prink_ratelimit() function from 2.6,
but I've not tested it yet. My goal is to use it there (and at other
places where messages can be triggered at will by a user).
About Solar Designer's concern about the string passed to printk, I'm
wondering if it would not be printk() itself which should strip
non printable chars. It would seem very strange to me that any part
of the kernel needs to send \n or \e via strings sent to printk. Well,
after having seen ugly code in some drivers, anything can be expected,
but we could try anyway.
It would be another patch anyway
Cheers,
Willy
> Signed-off-by: Ernie Petrides <petrides@redhat.com>
>
> --- linux-2.4.33/fs/binfmt_elf.c.orig
> +++ linux-2.4.33/fs/binfmt_elf.c
> @@ -77,7 +77,7 @@ static struct linux_binfmt elf_format =
> NULL, THIS_MODULE, load_elf_binary, load_elf_library, elf_core_dump, ELF_EXEC_PAGESIZE
> };
>
> -#define BAD_ADDR(x) ((unsigned long)(x) > TASK_SIZE)
> +#define BAD_ADDR(x) ((unsigned long)(x) >= TASK_SIZE)
>
> static int set_brk(unsigned long start, unsigned long end)
> {
> @@ -345,7 +345,7 @@ elf_type, total_size);
> * <= p_memsize so it is only necessary to check p_memsz.
> */
> k = load_addr + eppnt->p_vaddr;
> - if (k > TASK_SIZE || eppnt->p_filesz > eppnt->p_memsz ||
> + if (BAD_ADDR(k) || eppnt->p_filesz > eppnt->p_memsz ||
> eppnt->p_memsz > TASK_SIZE || TASK_SIZE - eppnt->p_memsz < k) {
> error = -ENOMEM;
> goto out_close;
> @@ -772,7 +772,7 @@ static int load_elf_binary(struct linux_
> * allowed task size. Note that p_filesz must always be
> * <= p_memsz so it is only necessary to check p_memsz.
> */
> - if (k > TASK_SIZE || elf_ppnt->p_filesz > elf_ppnt->p_memsz ||
> + if (BAD_ADDR(k) || elf_ppnt->p_filesz > elf_ppnt->p_memsz ||
> elf_ppnt->p_memsz > TASK_SIZE ||
> TASK_SIZE - elf_ppnt->p_memsz < k) {
> /* set_brk can never work. Avoid overflows. */
> @@ -822,10 +822,9 @@ static int load_elf_binary(struct linux_
> interpreter,
> &interp_load_addr);
> if (BAD_ADDR(elf_entry)) {
> - printk(KERN_ERR "Unable to load interpreter %.128s\n",
> - elf_interpreter);
> force_sig(SIGSEGV, current);
> - retval = IS_ERR((void *)elf_entry) ? PTR_ERR((void *)elf_entry) : -ENOEXEC;
> + retval = IS_ERR((void *)elf_entry) ?
> + (int)elf_entry : -EINVAL;
> goto out_free_dentry;
> }
> reloc_func_desc = interp_load_addr;
> @@ -833,6 +832,12 @@ static int load_elf_binary(struct linux_
> allow_write_access(interpreter);
> fput(interpreter);
> kfree(elf_interpreter);
> + } else {
> + if (BAD_ADDR(elf_entry)) {
> + force_sig(SIGSEGV, current);
> + retval = -EINVAL;
> + goto out_free_dentry;
> + }
> }
>
> kfree(elf_phdata);
prev parent reply other threads:[~2006-08-22 4:49 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-08-20 2:04 [PATCH x7] misc fixes from 2.4.33-ow1 Solar Designer
2006-08-20 9:15 ` [PATCH] binfmt_elf.c : the BAD_ADDR macro again Willy Tarreau
2006-08-20 15:51 ` Solar Designer
2006-08-20 16:23 ` Willy Tarreau
2006-08-21 20:35 ` Ernie Petrides
2006-08-21 21:11 ` Willy Tarreau
2006-08-21 23:36 ` Ernie Petrides
2006-08-22 3:07 ` printk()s of user-supplied strings (Re: [PATCH] binfmt_elf.c : the BAD_ADDR macro again) Solar Designer
2006-08-22 20:23 ` Ernie Petrides
2006-08-22 20:34 ` printk()s of user-supplied strings Willy Tarreau
2006-08-24 16:44 ` printk()s of user-supplied strings (Re: [PATCH] binfmt_elf.c : the BAD_ADDR macro again) Solar Designer
2006-08-24 16:46 ` Willy Tarreau
2006-08-26 2:29 ` Solar Designer
2006-08-26 8:22 ` Willy Tarreau
2006-08-26 23:13 ` Solar Designer
2006-08-27 20:04 ` printk()s of user-supplied strings Willy Tarreau
2006-08-28 1:52 ` Solar Designer
1970-01-01 0:16 ` Pavel Machek
2006-08-28 8:02 ` Willy Tarreau
2006-08-28 11:17 ` Krzysztof Halasa
2006-08-30 6:15 ` Willy Tarreau
2006-08-28 17:35 ` Valdis.Kletnieks
2006-08-22 4:36 ` Willy Tarreau [this message]
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=20060822043642.GB9489@1wt.eu \
--to=w@1wt.eu \
--cc=76306.1226@compuserve.com \
--cc=akpm@osdl.org \
--cc=linux-kernel@vger.kernel.org \
--cc=marcelo@kvack.org \
--cc=petrides@redhat.com \
--cc=solar@openwall.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®