Re: usb: Patch for USBDEVFS_IOCTL from 32-bit programs

[Pete Zaitcev <zaitcev@redhat.com>]

On Tue, 18 Oct 2005 11:05:33 -0400, Christopher Li <usb-devel@chrisli.org> wrote:
> On Tue, Oct 18, 2005 at 10:13:33AM -0700, Greg KH wrote:

> I am a little nervous no check have been done to what ioctl it is
> passing. Most of the case you don't need to convert the buffer, but
> what if there is some ioctl need to do something special.

You do not have to be nervous, because USB ioctls are not unstructured.
These ioctls do not receive __user pointers, unsigned longs, or things
freely interpreted. They are defined to receive one buffer, and they
are not expected to perform any copy_from_user/copy_to_user.

The struct file_operations has ioctl which looks like this:
        int (*ioctl) (struct inode *, struct file *, unsigned int, unsigned long);
The unsigned long here is often a pointer to user buffer.

However, in USB case, struct usb_driver has ioctl like this:
        int (*ioctl) (struct usb_interface *intf, unsigned int code, void *buf);
The *buf is not passed from user mode. It's an honest to goodness
kmalloc'ed buffer.

> On the safe side, I am expecting a big switch to list all the ioctl
> we known can safely pass, can grow the list when needed.

>From the above it should be obvious why such checking is entirely
unnecessary for the case of USB.

To be sure, one can write a driver which looks _inside_ the passed
*buf, and interpret the contents as a bunch of user pointers, in a
misguided attempt to create a DIY s/g capability, for instance.
If such a thing happens, we'd only have to identify the programmers
and impale them on a pole, then feed their intestines to crows.
That ought to take care of the problem without any checking lists.

-- Pete
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/