Re: bug in write(2) system call.

Chris Wedgwood (chris@cybernet.co.nz)
Tue, 20 Oct 1998 13:12:38 +1300


On Mon, Oct 19, 1998 at 09:24:27AM +0100, Tigran Aivazian wrote:

> It is true that you said POSIX does not specify it, not even Single
> UNIX v2... However, most existing Unix flavours, including Linux,
> document read,v(2)/write,v(2) (and many others) as returning EFAULT
> if the buf is outside of process' address space. Therefore either
> the manpage should be changed (hence cc: Andries) or the "issue"
> (not a bug, just issue) should be fixed.

I looked at this a couple on months back (and posted something to
security audit about some concerns I had).

Basically... if you pass bogus addresses and pointers to the kernel,
depending on what OS and version you are running, you might get an
EFAULT and you might not.

There is no wrong or right way - and no simple fix other than DON'T
PASS BOGUS POINTERS TO THE KERNEL.

In linux 2.0.x and more traditional kernels, the verify_area checks
will determine the address of bogus before reading or writing any
data, under 2.1.x and I think also NetBSD, if the start of the memory
range you spcific is legitimate, some data will be read and written.

I don't like the inconsistency much myself... but there doesn't seem
to be a sane way to handle this, and we are doing silly things in the
first place.

> Besides, as the original post came from Oracle, I presume the guys
> at Oracle are busy porting their products to Linux (which is good
> news!) and to have an implementation as friendly and as comfortable
> for applications as possible is in Linux's best interests :)

The post came from SCO, and even if it did come from Oracle, Oracle
shouldn't and probably doesn't pass null or bogus pointers to the
kernel.

If it did - it would break under WindowsNT which isn't terribly
resistant to this (well, sp3+ is pretty good, but previous flavours
will BSOD).

-cw

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/