From: Eric Anholt <eta@lclark.edu>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: "Robert T. Johnson" <rtjohnso@eecs.berkeley.edu>,
marcelo.tosatti@cyclades.com, faith@valinux.com,
DRI Devel <dri-devel@lists.sourceforge.net>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [Dri-devel] 2.4.23: user/kernel pointer bugs (drivers/char/vt.c, drivers/char/drm/gamma_dma.c)
Date: Thu, 08 Jan 2004 16:39:51 -0800 [thread overview]
Message-ID: <1073608790.713.13.camel@leguin> (raw)
In-Reply-To: <1073605921.13007.68.camel@dhcp23.swansea.linux.org.uk>
On Thu, 2004-01-08 at 15:52, Alan Cox wrote:
> On Iau, 2004-01-08 at 20:08, Robert T. Johnson wrote:
> > Both of these bugs look exploitable. The vt.c patch is
> > self-explanatory.
> >
> > In gamma_dma.c, argument "d" to gamma_dma_priority() points to a
> > structure copied from userspace (see gamma_dma()). That means that
> > d->send_indices is a pointer under user control, so it shouldn't be
> > dereferenced. The patch just safely copies the contents to a kernel
> > buffer and uses that instead. Ditto for d->send_sizes.
>
> Fortunately (in this case) Gamma hasn't worked since about 1999. The SiS
> DRM driver in XFree 4.4 snapshot is also exploitable although the 4.3
> one seems ok. If you feed the memory allocator random crap it oopses.
> With 4.3.x (ie the code in 2.4.x) it doesn't oops but requires sis_fb.
> With 4.3.99... it oopses if I dont have sisfb.
Uhoh, the SiS is my fault. I'll take a look soon.
> > Also, I notice the drm code uses it's own memory allocation wrappers. I
> > don't know all the details of the drm code, so I just used kmalloc.
> > You'll probably want to change those two calls after applying the
> > patch. Sorry for the inconvenience.
>
> It comes out as kmalloc, but its done so it will be portable to other
> systems. So on *BSD it comes out appropriately too.
Actually, they were wrapped originally because there was a bunch of
debugging and statistics code for memory allocation. That's been axed
because nobody actually used it, so now they're just left as functions
wrapping the OS's malloc/free.
--
Eric Anholt eta@lclark.edu
http://people.freebsd.org/~anholt/ anholt@FreeBSD.org
next prev parent reply other threads:[~2004-01-09 0:38 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-01-08 20:08 Robert T. Johnson
2004-01-08 23:52 ` [Dri-devel] " Alan Cox
2004-01-09 0:39 ` Eric Anholt [this message]
2004-01-09 0:38 ` Alan Cox
2004-01-10 17:46 ` Marcelo Tosatti
2004-01-10 21:30 ` Robert T. Johnson
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=1073608790.713.13.camel@leguin \
--to=eta@lclark.edu \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=dri-devel@lists.sourceforge.net \
--cc=faith@valinux.com \
--cc=linux-kernel@vger.kernel.org \
--cc=marcelo.tosatti@cyclades.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome