linux-origin
[Top] [All Lists]

Re: sys32_newstat() and friends

To: Kanoj Sarcar <kanoj@xxxxxxxxxxxxxxxxxxx>
Subject: Re: sys32_newstat() and friends
From: Ralf Baechle <ralf@xxxxxxxxxxx>
Date: Fri, 7 Jul 2000 01:24:36 +0200
Cc: linux-origin@xxxxxxxxxxx
In-reply-to: <200007062227.PAA20540@xxxxxxxxxxxxxxxxxxx>; from kanoj@xxxxxxxxxxxxxxxxxxx on Thu, Jul 06, 2000 at 03:27:43PM -0700
References: <20000706130547.A6744@xxxxxxxxxxxxxxxx> <200007062227.PAA20540@xxxxxxxxxxxxxxxxxxx>
Sender: owner-linux-origin@xxxxxxxxxxx
On Thu, Jul 06, 2000 at 03:27:43PM -0700, Kanoj Sarcar wrote:

> > Note that set_fs(KERNEL_DS) also allows the filename to be fetched from
> > anywhere in memory including kernel space resulting in a potencial
> > information leak or crash.
> 
> Define how you can get a information leak or crash. I haven't looked
> too closely, but I assume the fs/namei.c routines protect themselves.
> In any case, most other ioctls on 64 bit platforms have this same problem
> then.

Nope, these routines don't - and can't protect themselfes.  The user has
to set_fs() correctly and that's broken in these functions.

Information leak - it's not exactly a superconvenient peephole into the
kernelspace.  Assume you want to read a certain address space in memory.
To do so you have to guess that memory's content.  If you guess right
you'll stat some random object on the fs.  You can guess which one it
was from the inode number.

Crash - there are some hardware registers which don't like to be read.
Point the filename argument to one of those and poof, game over.  For now
some pointer to non-decoded address space should do, you get a DBE
exception, game over.

  Ralf

<Prev in Thread] Current Thread [Next in Thread>