From: Linus Torvalds <torvalds@linux-foundation.org>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Gerald Schaefer <gerald.schaefer@de.ibm.com>,
roland@redhat.com, linux-kernel@vger.kernel.org,
schwidefsky@de.ibm.com, heiko.carstens@de.ibm.com
Subject: Re: [BUG] binfmt_elf: get_user() called in vma_dump_size() after set_fs(KERNEL_DS)
Date: Fri, 6 Feb 2009 13:57:18 -0800 (PST) [thread overview]
Message-ID: <alpine.LFD.2.00.0902061351390.3048@localhost.localdomain> (raw)
In-Reply-To: <20090206134410.d548b72c.akpm@linux-foundation.org>
On Fri, 6 Feb 2009, Andrew Morton wrote:
> On Fri, 06 Feb 2009 18:10:35 +0100
> Gerald Schaefer <gerald.schaefer@de.ibm.com> wrote:
> >
> > elf_core_dump() does a set_fs(KERNEL_DS) and then calls vma_dump_size(),
> > which uses get_user() to check for an ELF header at vma->vm_start in the
> > user mapping. This is a bug because vm_start is a user virtual address and
> > get_user() will fail or even read from a kernel address (KERNEL_DS).
> >
> > Maybe a get_user_pages() should be used to get the user data, or a temporary
> > set_fs(USER_DS)?
> >
>
> Could use __get_user() to skip the access_ok() check?
That's not the problem.
The problem is that
(a) some architectures actually use separate address spaces (sparc, at
least), so using "get_user()" while you are in KERNEL_DS will
literally access the wrong thing.
__get_user doesn't affect this part.
(b) the security one: KERNEL_DS will change the access checks that
get_user() does, and allow access to kernel memory.
Using __get_user _does_ affect this part by removing the checks, but
since the problem was that KERNEL_DS already _weakened_ the checks,
removign the too-weak checking doesn't actually help.
> We'd need to be sure that the address isn't a kernel address or iomem
> or something.
As mentioned, even this won't actually help. On at least some sparc
machines (sparc64?), memory accesses really are segmented, with different
address spaces for user and kernel mode, so a user and kernel address may
actually have the exact same pointer value, but point to different memory!
So you can't just check the address. You really have to do the whole
"set_fs()" thing to set the segment register.
Linus
next prev parent reply other threads:[~2009-02-06 21:57 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-02-06 17:10 Gerald Schaefer
2009-02-06 21:44 ` Andrew Morton
2009-02-06 21:57 ` Linus Torvalds [this message]
2009-02-06 22:07 ` Roland McGrath
2009-02-06 22:18 ` David Miller
2009-02-06 22:19 ` Linus Torvalds
2009-02-07 1:55 ` [PATCH] elf core dump: fix get_user use Roland McGrath
2009-02-07 1:55 ` [BUG] binfmt_elf: get_user() called in vma_dump_size() after set_fs(KERNEL_DS) Roland McGrath
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=alpine.LFD.2.00.0902061351390.3048@localhost.localdomain \
--to=torvalds@linux-foundation.org \
--cc=akpm@linux-foundation.org \
--cc=gerald.schaefer@de.ibm.com \
--cc=heiko.carstens@de.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=roland@redhat.com \
--cc=schwidefsky@de.ibm.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®