All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michael Buesch <mb@bu3sch.de>
To: "linux-os (Dick Johnson)" <linux-os@analogic.com>
Cc: "linux-kernel" <linux-kernel@vger.kernel.org>
Subject: Re: Really good idea to allow mmap(0, FIXED)?
Date: Fri, 6 Oct 2006 16:40:59 +0200	[thread overview]
Message-ID: <200610061640.59421.mb@bu3sch.de> (raw)
In-Reply-To: <Pine.LNX.4.61.0610051535420.29755@chaos.analogic.com>

On Thursday 05 October 2006 21:50, linux-os (Dick Johnson) wrote:
> Of course you must be able to remap the physical address 0 (offset
> zero in the whole machine), and if your 'hint' to mmap() in
> user code is a 0, it can (it's allowed) to return a pointer
> initialized to zero --and it's your fault if it's incompatible
> with some 'C' runtime libraries.
> 
> It is a perfectly good address and the fact that malloc() returns
> (void *)0 upon failure, does not qualify it as king or some other
> ruler. In fact, mmap() returns (void *)-1 upon failure.

You are explainint something that is _completely_ unrelated to the
issue I am describing.

> > I say no, because this can potentially be used to turn rather harmless
> > kernel bugs into a security vulnerability.
> >
> 
> Can't. The kernel doesn't check for NULL for user access, it
> simply traps if the address is bad. That's why we have copy/to/from_user()
> for user-mode access.

See my example.

> > Let's say we have some kernel NULL pointer dereference bug somewhere,
> > that's rather harmless, if it happens in process context and
> > does not leak any resources on segfaulting the triggering app.
> > So the worst thing that happens is a crashing app. Yeah, this bug must
> > be fixed. But my point is that this bug can probably be used to
> > manipulate the way the kernel works or even to inject code into
> > the kernel from userspace.
> >
> 
> Can't.

See my example. It _does_ inject a userspace controlled value into
the kernel.

> > Attached to this mail is an example. The kernel module represents
> > the actual "kernel-bug". Its whole purpose in this example is to
> > introduce a user-triggerable NULL pointer dereference.
> > Please stop typing now, if you are typing something like
> > "If you can load a kernel module, you have access to the kernel anyway".
> > This is different. We always _had_ and most likely _have_ NULL pointer
> > dereference bugs in the kernel.
> >
> > The example programm injects a magic value 0xB15B00B2 into the
> > kernel, which is printk'ed on success.
> 
> Well this shows nothing interesting.

It _does_. What if the pointer was a function pointer and the
kernel executed it? Eh? It would continue to execute userspace
controlled code.

> >
> > In my opinion, this should be forbidden by disallowing mmapping
> > to address 0. A NULL pointer dereference is such a common bug, that
> > it is worth protecting against.
> > Besides that, I currently don't see a valid reason to mmap address 0.
> >
> 
> That's where the real-mode BIOS table is. Who says that I can't
> look at any piece of physical memory I want. It's my machine.

Doing it in the kernel and not from unprivileged user processes
would be a good idea for this anyway...

> The whole concept of a NULL pointer is simply an artifact of
> incorrect engineering.

I do _NOT_ complain about the NULL pointer. You simply did not get
my point.

-- 
Greetings Michael.

  reply	other threads:[~2006-10-06 14:41 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-10-05 18:59 Really good idea to allow mmap(0, FIXED)? Michael Buesch
2006-10-05 19:50 ` linux-os (Dick Johnson)
2006-10-06 14:40   ` Michael Buesch [this message]
2006-10-05 21:58 ` Alan Cox
2006-10-06 14:44   ` Michael Buesch
2006-10-07 11:23     ` Pavel Machek
2006-10-05 23:55 ` David Wagner
2006-10-06  4:34   ` Jeremy Fitzhardinge
2006-10-06  5:39   ` Jan Engelhardt
2006-10-06 19:47     ` David Wagner
2006-10-06  7:25   ` Arjan van de Ven
2006-10-06 10:36     ` Mikael Pettersson
2006-10-06 11:20       ` Arjan van de Ven
2006-10-06 19:43     ` David Wagner
2006-10-08  0:22       ` Jeremy Fitzhardinge
2006-10-08  2:03         ` David Wagner
2006-10-08 19:18         ` Michael Buesch
2006-10-06 14:55 ` Michael Buesch

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=200610061640.59421.mb@bu3sch.de \
    --to=mb@bu3sch.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-os@analogic.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 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.