[7415] in bugtraq

home help back first fref pref prev next nref lref last post

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

home help back first fref pref prev next nref lref last post