On Mon, 2011-03-14 at 21:22 -0700, Roland Dreier wrote: > On Mon, Mar 14, 2011 at 7:27 PM, Roland Dreier <rol...@kernel.org> wrote: > > Doesn't that mean unprivileged userspace could trigger a use-after-free > > in the kernel? (and it might be malicious code, not buggy userspace) > > >From reading the code a bit, I guess ucma is OK in this area. I do see > what seems like an exploitable race in ucma_create_id(): > > - one thread create an id with an invalid userspace pointer > (so the copy_to_user in ucma_create_id returns -EFAULT > and calls rdma_destroy_id before idr_remove) > - another thread guess the id that is going to be returned and > call ucma_destroy_id() > > if the second thread hits the window where the cm_id is > destroyed but the ctx is still in the idr, it can trigger a double free. > > But this is a completely different bug. > > - R.
Heh, nice. This would be a good example of why I prefer that rules such
as "cm_destroy_id/rdma_destroy_id/ucma_destroy_id can only be called
once per ID" be coded into the destroy function themselves and enforced.
As long as you are talking about user space guessing ID's, it is
patently impossible to guarantee that we won't call a destroy function
more than once.
--
Doug Ledford <dledf...@redhat.com>
GPG KeyID: CFBFF194
http://people.redhat.com/dledford
Infiniband specific RPMs available at
http://people.redhat.com/dledford/Infiniband
signature.asc
Description: This is a digitally signed message part
