[7418] in bugtraq
Re: Fwd: Any user can panic OpenBSD machine
daemon@ATHENA.MIT.EDU (J.R. Valverde)
Tue Jul 28 14:19:55 1998
Date: Tue, 28 Jul 1998 11:47:23 +0200
Reply-To: "J.R. Valverde" <jrvalverde@cnb.uam.es>
From: "J.R. Valverde" <jrvalverde@CNB.UAM.ES>
To: BUGTRAQ@NETSPACE.ORG
In-Reply-To: <199807272138.PAA08789@harmony.village.org>
> Even though the values are declared u_int, they seem to be used in the
> code as signed numbers (maybe that's a problem), so return EINVAL for
> a number, cast to signed, that is negative seems appropriate.
Under no circumstances at all. If the error is raised by the compiler
and the code rejected unless a correction is made, then it may be OK,
but on run time the "-1" does NOT exist at all, it is only a pattern
of zeroes and ones, which might as well be a valid unsigned value.
Rejecting such patterns on the premise that the programmer might had made
a mistake and used a negative number in the code fails to consider the
case where the programmer actually intended to use such a big unsigned
value.
If the var is an u_int then every bit pattern that can be interpreted as
an unsigned integer should be accepted. Otherwise it should be declared
a different type or an acceptable range of values stated clearly
somewhere and tested through appropriate variable/constants/macros.
What if next computer generation allows for bigger iov_len values and
there is room for valid values bigger than 2**31 + 1? What if the machine
uses a different convention for representing sign? What if...?
The problem is not that the bit pattern *might* have been interpreted as
a negative number by a hypothetical human, but that the acceptable limits
are note well defined/tested.
The code should not test the hypothetical intetion of a hypothetical
sloppy programmer disregarding possibly legit values. It should define
legal values and test them, nothing more, nothing less.
jr
