From: viro@parcelfarce.linux.theplanet.co.uk
To: "Robert T. Johnson" <rtjohnso@eecs.berkeley.edu>
Cc: linux-fbdev-devel@lists.sourceforge.net,
Linux Kernel <linux-kernel@vger.kernel.org>
Subject: Re: PATCH: 2.6.7-rc3 drivers/video/fbmem.c: user/kernel pointer bugs
Date: Thu, 10 Jun 2004 02:24:41 +0100 [thread overview]
Message-ID: <20040610012441.GY12308@parcelfarce.linux.theplanet.co.uk> (raw)
In-Reply-To: <1086821199.32054.111.camel@dooby.cs.berkeley.edu>
On Wed, Jun 09, 2004 at 03:46:39PM -0700, Robert T. Johnson wrote:
> Since sprite is a user pointer, reading sprite->mask or sprite->image.data
> requires unsafe dereferences. Let me know if you have any questions or if
> I've made a mistake.
Nice catch. IMO drivers/video/* is too damn scary to get in there and look
for now - as long as there are less nasty areas to deal with ;-)
BTW, had con_font_op() shown up in your checks? It _does_ avoid dereferencing
userland pointers in a very similar scenario, but proving that is not something
I'd wish on any code. Short version of the story:
* console_font_op ->data can be a userland pointer. It is obtained
from ioctls on many paths; all end up passing the (kernel) pointer to
structure to con_font_op().
* a lot of code in drivers uses struct console_font_op. And
dereferences ->data.
* con_font_op() checks op->op and if it is KD_FONT_OP_[SG]ET, op->data
gets moved to kernel. In any case, op is passed to the same method -
->con_font_op(). In some cases - with kernel pointer in ->data, in some -
with userland one.
* ->con_font_op() in drivers does not dereference op->data unless
op->op is one of those two.
Oh, and to make life even funnier, struct console_font_op is also misused to
store current font.
I wonder what did cqual say about that one - it sure as hell should raise a lot
of red flags and the last item (none of the drivers dereference ->data unless
->op is one of KD_FONT_OP_{S,G}ET) is going to be hell on anything short of
full AI. sparse does *not* figure out that it's safe and raises hell over
->data not being declared as userland pointer while getting copy_..._user()
on it.
FWIW, I think we should reduxe mixing of ioctl and kernel structures.
console_font_op is a particulary obnoxious example, but lots of the stuff
in drivers/video is not much better.
-------------------------------------------------------
This SF.Net email is sponsored by: GNOME Foundation
Hackers Unite! GUADEC: The world's #1 Open Source Desktop Event.
GNOME Users and Developers European Conference, 28-30th June in Norway
http://2004/guadec.org
WARNING: multiple messages have this Message-ID (diff)
From: viro@parcelfarce.linux.theplanet.co.uk
To: "Robert T. Johnson" <rtjohnso@eecs.berkeley.edu>
Cc: linux-fbdev-devel@lists.sourceforge.net,
Linux Kernel <linux-kernel@vger.kernel.org>
Subject: Re: PATCH: 2.6.7-rc3 drivers/video/fbmem.c: user/kernel pointer bugs
Date: Thu, 10 Jun 2004 02:24:41 +0100 [thread overview]
Message-ID: <20040610012441.GY12308@parcelfarce.linux.theplanet.co.uk> (raw)
In-Reply-To: <1086821199.32054.111.camel@dooby.cs.berkeley.edu>
On Wed, Jun 09, 2004 at 03:46:39PM -0700, Robert T. Johnson wrote:
> Since sprite is a user pointer, reading sprite->mask or sprite->image.data
> requires unsafe dereferences. Let me know if you have any questions or if
> I've made a mistake.
Nice catch. IMO drivers/video/* is too damn scary to get in there and look
for now - as long as there are less nasty areas to deal with ;-)
BTW, had con_font_op() shown up in your checks? It _does_ avoid dereferencing
userland pointers in a very similar scenario, but proving that is not something
I'd wish on any code. Short version of the story:
* console_font_op ->data can be a userland pointer. It is obtained
from ioctls on many paths; all end up passing the (kernel) pointer to
structure to con_font_op().
* a lot of code in drivers uses struct console_font_op. And
dereferences ->data.
* con_font_op() checks op->op and if it is KD_FONT_OP_[SG]ET, op->data
gets moved to kernel. In any case, op is passed to the same method -
->con_font_op(). In some cases - with kernel pointer in ->data, in some -
with userland one.
* ->con_font_op() in drivers does not dereference op->data unless
op->op is one of those two.
Oh, and to make life even funnier, struct console_font_op is also misused to
store current font.
I wonder what did cqual say about that one - it sure as hell should raise a lot
of red flags and the last item (none of the drivers dereference ->data unless
->op is one of KD_FONT_OP_{S,G}ET) is going to be hell on anything short of
full AI. sparse does *not* figure out that it's safe and raises hell over
->data not being declared as userland pointer while getting copy_..._user()
on it.
FWIW, I think we should reduxe mixing of ioctl and kernel structures.
console_font_op is a particulary obnoxious example, but lots of the stuff
in drivers/video is not much better.
next prev parent reply other threads:[~2004-06-10 1:24 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-06-09 22:46 PATCH: 2.6.7-rc3 drivers/video/fbmem.c: user/kernel pointer bugs Robert T. Johnson
2004-06-10 1:24 ` viro [this message]
2004-06-10 1:24 ` viro
2004-06-10 3:50 ` Robert T. Johnson
2004-06-10 3:50 ` Robert T. Johnson
2004-06-10 4:15 ` viro
2004-06-10 4:15 ` viro
2004-06-10 5:00 ` Robert T. Johnson
2004-06-10 5:00 ` Robert T. Johnson
2004-06-10 9:15 ` Geert Uytterhoeven
2004-06-10 9:15 ` [Linux-fbdev-devel] " Geert Uytterhoeven
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=20040610012441.GY12308@parcelfarce.linux.theplanet.co.uk \
--to=viro@parcelfarce.linux.theplanet.co.uk \
--cc=linux-fbdev-devel@lists.sourceforge.net \
--cc=linux-kernel@vger.kernel.org \
--cc=rtjohnso@eecs.berkeley.edu \
/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.