Re: Bogus buffer length check in linux-2.6.11 read()

From: linux-os
Date: Wed Mar 16 2005 - 09:15:26 EST


On Wed, 16 Mar 2005, Ian Campbell wrote:


On Wed, 2005-03-16 at 07:29 -0500, linux-os wrote:

This means that the read() is no longer perfectly happy
to corrupt all of the user's memory which is the defacto
correct response for a bad buffer as shown. Instead, some
added "check in software" claims to prevent this, but
is wrong anyway because it can't possibly know how much
data area is available.

The manpage for read(2) that I've got says

EFAULT buf is outside your accessible address space.

which is exactly what it would appear
if (unlikely(!access_ok(VERIFY_WRITE, buf, count)))
return -EFAULT;
checks for. Assuming this is the check you are bitching about -- you
could be a little more precise if you are going to complain about stuff.

Ian.


I don't know how much more precise I could have been. I show the
code that will cause the observed condition. I explain that this
condition is new, that it doesn't correspond to the previous
behavior.

Never before was some buffer checked for length before some data
was written to it. The EFAULT is supposed to occur IFF a write
attempt occurs outside the caller's accessible address space.
This used to be done by hardware during the write to user-space.
This had zero impact upon performance. Now there is some
software added that adds CPU cycles, subtracts performance,
and cannot possibly do anything useful.

Also, the code was written to show the problem. The code
is not designed to be an example of good coding practice.

The actual problem observed with the new kernel was
when some legacy code used gets() instead of fgets().
The call returned immediately with an EFAULT because
the 'C' runtime library put some value that the kernel
didn't 'like' (4096 bytes) in the subsequent read.

This is code for which there are no sources available
and it is required to be used, cannot be replaced,
cannot be thrown away and costs about US$ 10,000
from a company that is no longer in business.

Somebody's arbitrary and capricious addition of spook
code destroyed an application's functionality.

Cheers,
Dick Johnson
Penguin : Linux version 2.6.11 on an i686 machine (5537.79 BogoMips).
Notice : All mail here is now cached for review by Dictator Bush.
98.36% of all statistics are fiction.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/