Re: Implementation defined behaviour in read_write.c

[Rainer Weikusat <rainer.weikusat@sncag.com>]

Alan Cox <alan@lxorguk.ukuu.org.uk> writes:
> On Llu, 2004-09-20 at 16:54, Rainer Weikusat wrote:
>> The following code is in the function do_readv_writev in the file
>> fs/read_write.c (2.6.8.1):
>
> The 2.4.x kernel has part of this fixed. In particular it does the
> overflow check differently because gcc 3.x in some forms did appear to
> be making use of the undefined nature of the test and that was a
> potential security hole. ("its undefined lets say its always
> false.."). The initial cast and test should be fine.

I assume you mean the cast at the beginning of the loop. According to
the C-standard, both cases are exactly the same (they are both
conversions of potentially nonrepresentable values).

	6.3.1.3 Signed and unsigned integers

	When a value with integer type is converted to another integer
	type other than _Bool, if the value can be represented by the
	new type, it is unchanged.

	[...]

	Otherwise, the new type is signed and the value cannot be
	represented in it; either the result is implementation-defined
	or an implementation-defined signal is raised.

The requirement for implementation defined is that the implementation
documents the behaviour (which gcc at least up to 3.4.4 doesn't). This
not a problem with the current compiler, but I happen to know by
coincedence that some people of unknown relations to the gcc team
(like the person who wrote this advisory:
<URL:http://cert.uni-stuttgart.de/advisories/c-integer-overflow.php>)
would like to turn it into a problem, because they strongly believe it
is "the right thing to do", so it may be unwise to rely on gcc for
treating this sanely, ie so that it doesn't break idioms which are in
rather common use.