On Mon, Jul 20, 2009 at 01:00:00PM +0200, Michael Buesch wrote:
> On Monday 20 July 2009 08:24:20 Greg KH wrote:
> > On Fri, Jul 17, 2009 at 11:54:33PM +0200, Michael Buesch wrote:
> > > I was wondering whether the following patch could make sense.
> > > The compat ioctl code uses get_user() to fetch all integers, but
> > > uses __get_user() to fetch the pointer. But I don't see who checked access_ok()
> > > on the pointer member of the compat struct in userspace.
> > >
> > > The native IOCTL does check access_ok() on the pointer (via copy_from_user() on
> > > the whole struct usbdevfs_ioctl)
> > >
> > > What happens to __get_user() if access is not OK? Does it crash? Does it silently return
> > > and leave udata uninitialized (= initialized with stack junk). Both would be pretty bad.
> >
> > I'm pretty sure that is up to the compat_ptr() call, right? That
> > happens right below the __copy_user().
>
>
> Hm, well. compat_ptr() basically is just a typecast (and 64bit extension on 64bit):
>
> 195 typedef u32 compat_uptr_t;
> 196
> 197 static inline void __user *compat_ptr(compat_uptr_t uptr)
> 198 {
> 199 return (void __user *)(unsigned long)uptr;
> 200 }
which is fine on x86, right?
What about other arches?
thanks,
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
