Re: [PATCH] remember to check return value from __copy_to_user() incdrom_read_cdda_old()

[Andrew Morton]

Jens Axboe <axboe@xxxxxxx> wrote:
>
> On Tue, Sep 07 2004, Andrew Morton wrote:
> > Jens Axboe <axboe@xxxxxxx> wrote:
> > >
> > > On Tue, Sep 07 2004, Paul Mackerras wrote:
> > > > Jens Axboe writes:
> > > > 
> > > > > __copy_to_user is the unchecking version of copy_to_user.
> > > > 
> > > > It doesn't range-check the address, but it does return non-zero
> > > > (number of bytes not copied) if it encounters a fault writing to the
> > > > user buffer.
> > > 
> > > but it doesn't matter, if it returns non-zero then something happened
> > > between the access_ok() and the actual copy because the user app did
> > > something silly. so I don't care much really, I think the major point is
> > > the kernel will cope.
> > > 
> > > you could remove the access_ok() and change it to a copy_to_user()
> > > instead, I don't care either way. it's the old and slow interface which
> > > really never is used unless things have gone wrong anyways.
> > > 
> > 
> > Sure, but at present if an application tries to read cdrom data to address
> > 0x00000000 (say), the kernel will return "success".  It should return an
> > error code.  (Actually, it should return a short read if any data was
> > transferred, but whatever).
> 
> Because access_ok() isn't reliable?

access_ok() simply checks that the address is in the 0x00000000 -
0xbfffffff range.  We can still get faults in that range.


> There is another bug in there though, ret is never returned if
> cdrom_read_block() fails.

yup.
-
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/