[7422] in bugtraq
Re: Fwd: Any user can panic OpenBSD machine
daemon@ATHENA.MIT.EDU (Gert Doering)
Tue Jul 28 15:24:29 1998
Date: Tue, 28 Jul 1998 19:13:52 +0200
Reply-To: Gert Doering <gert@GREENIE.MUC.DE>
From: Gert Doering <gert@GREENIE.MUC.DE>
X-To: chris@CYBERNET.CO.NZ
To: BUGTRAQ@NETSPACE.ORG
In-Reply-To: <19980728150850.A3549@caffeine.ix.net.nz> from Chris Wedgwood at
"Jul 28, 98 03:08:50 pm"
Hi,
Chris Wedgwood wrote:
> 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.
The reason why this works is clear. Linux 2.1 doesn't explicitely check
the size given anymore (this just consumes CPU time, without giving any
benefits).
If the result of the read[v]() doesn't fit into the memory allocated to
that program, the CPU will fault -> EFAULT.
*If* it fits (read() calls from a device are allowed to return partial
defaults, for example, one line at a time from a tty-like device), then
there is no error from the kernel side. After all, who knows how big the
buffers are? Who cares, as long as they are "large enough"?
gert
--
USENET is *not* the non-clickable part of WWW!
//www.muc.de/~gert/
Gert Doering - Munich, Germany gert@greenie.muc.de
fax: +49-89-35655025 gert.doering@physik.tu-muenchen.de
