On Thu, May 18, 2000 at 07:52:28AM -0700, C J Considine wrote:
> As the structures returned from e.g. ioctl(fdev0,HDIO_GET_IDENTITY,&id)
> change in length now and then, and the user include files are separate
> from the kernel include files it seems that a length and possibly a
> version number constant would be very smart 4th and 5th parameters.
> They would prevent over-running the length of the supplied buffer and
> trashing the stack or whatever. This might also avoid future exploits.
Linux kernel has heaps of IOCTL codes which are not using
very sensible encoding rules: ( <asm/ioctl.h> )
/* ioctl command encoding: 32 bits total, command in lower 16 bits,
* size of the parameter structure in the lower 14 bits of the
* upper 16 bits.
* Encoding the size of the parameter structure in the ioctl request
* is useful for catching programs compiled with old versions
* and to avoid overwriting user space outside the user buffer area.
* The highest 2 bits are reserved for indicating the ``access mode''.
* NOTE: This limits the max parameter size to 16kB -1 !
*/
/*
* The following is for compatibility across the various Linux
* platforms. The i386 ioctl numbering scheme doesn't really enforce
* a type field. De facto, however, the top 8 bits of the lower 16
* bits are indeed used as a type field, so we might just as well make
* this explicit here. Please be sure to use the decoding macros
* below from now on.
*/
That is: 2+14+8+8 bits of "mode"+"size"+"type"+"number"
If you have some spare time, scanning thru the sources to find
all IOCTL codes not using these rules would be usefull thing
for further development. Perhaps for introducing new codes,
along with old compability ones, or just helping audit things.
/Matti Aarnio <matti.aarnio@sonera.fi>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue May 23 2000 - 21:00:15 EST