[7415] in bugtraq
Re: Fwd: Any user can panic OpenBSD machine
daemon@ATHENA.MIT.EDU (Chris Wedgwood)
Tue Jul 28 14:19:48 1998
Date: Tue, 28 Jul 1998 15:08:50 +1200
Reply-To: Chris Wedgwood <chris@CYBERNET.CO.NZ>
From: Chris Wedgwood <chris@CYBERNET.CO.NZ>
To: BUGTRAQ@NETSPACE.ORG
In-Reply-To: <19980728093418.A15420@caffeine.ix.net.nz>; from Chris Wedgwood
on Tue, Jul 28, 1998 at 09:34:18AM +1200
On Tue, Jul 28, 1998 at 09:34:18AM +1200, Chris Wedgwood wrote:
> Just for the hell of it, I tested this under linux 2.1.x - no problems.
>
> Not, according to the source in front of me, the size is actually 2^32-1 (or
> 2^64-1 on 64-bit platforms), not negative because the length parameter is of
> type size_t which is an unsigned integer.
>
> It does not return EINVAL (as, I believe, somebody else reported).
I lied, partly anyhow. (Thanks to Scott Stone <sstone@ume.pht.co.jp>
for pointing out 2.0.x fails with EFAULT).
Linux 2.0.x fails with EFAULT, which, arguably, is the correct thing
to do because the memory region specified using 2^32-1 can't possible
all exist.
Linux 2.1.x (where x is my hacked up 10x kernel) sometimes succeeds,
which is completely bogus and should be considered a bug of a
different sort.
Here, when the fd is 0 (or open("/dev/tty<blah>",O_RDONLY)), is
will accept data from stdin/the-device and return it correctly.
When the fd belongs to a file, it returns EFAULT as it should
(which rules out the possibility of opening /dev/zero and doing bad
things).
I'm not sure why this is happening... I'll look into it later if
nobody else does.
-cw