drivers/gpu/drm/virtio/virtgpu_ioctl.c | 19 +++++++++++++++++-- 1 file changed, 17 insertions(+), 2 deletions(-)
From: Rob Clark <robdclark@chromium.org>
Userspace can guess the handle value and try to race GEM object creation
with handle close, resulting in a use-after-free if we dereference the
object after dropping the handle's reference. For that reason, dropping
the handle's reference must be done *after* we are done dereferencing
the object.
Signed-off-by: Rob Clark <robdclark@chromium.org>
---
drivers/gpu/drm/virtio/virtgpu_ioctl.c | 19 +++++++++++++++++--
1 file changed, 17 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_ioctl.c b/drivers/gpu/drm/virtio/virtgpu_ioctl.c
index a5cccccb4998..f1c55c1630ca 100644
--- a/drivers/gpu/drm/virtio/virtgpu_ioctl.c
+++ b/drivers/gpu/drm/virtio/virtgpu_ioctl.c
@@ -366,10 +366,18 @@ static int virtio_gpu_resource_create_ioctl(struct drm_device *dev, void *data,
drm_gem_object_release(obj);
return ret;
}
- drm_gem_object_put(obj);
rc->res_handle = qobj->hw_res_handle; /* similiar to a VM address */
rc->bo_handle = handle;
+
+ /*
+ * The handle owns the reference now. But we must drop our
+ * remaining reference *after* we no longer need to dereference
+ * the obj. Otherwise userspace could guess the handle and
+ * race closing it from another thread.
+ */
+ drm_gem_object_put(obj);
+
return 0;
}
@@ -731,11 +739,18 @@ static int virtio_gpu_resource_create_blob_ioctl(struct drm_device *dev,
drm_gem_object_release(obj);
return ret;
}
- drm_gem_object_put(obj);
rc_blob->res_handle = bo->hw_res_handle;
rc_blob->bo_handle = handle;
+ /*
+ * The handle owns the reference now. But we must drop our
+ * remaining reference *after* we no longer need to dereference
+ * the obj. Otherwise userspace could guess the handle and
+ * race closing it from another thread.
+ */
+ drm_gem_object_put(obj);
+
return 0;
}
--
2.38.1
On 12/17/22 02:33, Rob Clark wrote: > From: Rob Clark <robdclark@chromium.org> > > Userspace can guess the handle value and try to race GEM object creation > with handle close, resulting in a use-after-free if we dereference the > object after dropping the handle's reference. For that reason, dropping > the handle's reference must be done *after* we are done dereferencing > the object. > > Signed-off-by: Rob Clark <robdclark@chromium.org> > --- > drivers/gpu/drm/virtio/virtgpu_ioctl.c | 19 +++++++++++++++++-- > 1 file changed, 17 insertions(+), 2 deletions(-) Added fixes/stable tags and applied this virtio-gpu patch to misc-fixes. The Panfrost patch is untouched. -- Best regards, Dmitry
On Mon, Jan 9, 2023 at 3:28 PM Dmitry Osipenko <dmitry.osipenko@collabora.com> wrote: > > On 12/17/22 02:33, Rob Clark wrote: > > From: Rob Clark <robdclark@chromium.org> > > > > Userspace can guess the handle value and try to race GEM object creation > > with handle close, resulting in a use-after-free if we dereference the > > object after dropping the handle's reference. For that reason, dropping > > the handle's reference must be done *after* we are done dereferencing > > the object. > > > > Signed-off-by: Rob Clark <robdclark@chromium.org> > > --- > > drivers/gpu/drm/virtio/virtgpu_ioctl.c | 19 +++++++++++++++++-- > > 1 file changed, 17 insertions(+), 2 deletions(-) > > Added fixes/stable tags and applied this virtio-gpu patch to misc-fixes. > The Panfrost patch is untouched. Thanks.. the panfrost patch was not intended to be part of the same series (but apparently that is what happens when I send them at the same time), and was superceded by a patch from Steven Price (commit 4217c6ac8174 ("drm/panfrost: Fix GEM handle creation ref-counting") already applied to misc-fixes BR, -R
On 1/10/23 04:47, Rob Clark wrote: > On Mon, Jan 9, 2023 at 3:28 PM Dmitry Osipenko > <dmitry.osipenko@collabora.com> wrote: >> >> On 12/17/22 02:33, Rob Clark wrote: >>> From: Rob Clark <robdclark@chromium.org> >>> >>> Userspace can guess the handle value and try to race GEM object creation >>> with handle close, resulting in a use-after-free if we dereference the >>> object after dropping the handle's reference. For that reason, dropping >>> the handle's reference must be done *after* we are done dereferencing >>> the object. >>> >>> Signed-off-by: Rob Clark <robdclark@chromium.org> >>> --- >>> drivers/gpu/drm/virtio/virtgpu_ioctl.c | 19 +++++++++++++++++-- >>> 1 file changed, 17 insertions(+), 2 deletions(-) >> >> Added fixes/stable tags and applied this virtio-gpu patch to misc-fixes. >> The Panfrost patch is untouched. > > Thanks.. the panfrost patch was not intended to be part of the same > series (but apparently that is what happens when I send them at the > same time), and was superceded by a patch from Steven Price (commit > 4217c6ac8174 ("drm/panfrost: Fix GEM handle creation ref-counting") > already applied to misc-fixes Okay, I wanted to make clear what has been applied. -- Best regards, Dmitry
On Fri, Dec 16, 2022 at 3:33 PM Rob Clark <robdclark@gmail.com> wrote: > > From: Rob Clark <robdclark@chromium.org> > > Userspace can guess the handle value and try to race GEM object creation > with handle close, resulting in a use-after-free if we dereference the > object after dropping the handle's reference. For that reason, dropping > the handle's reference must be done *after* we are done dereferencing > the object. > > Signed-off-by: Rob Clark <robdclark@chromium.org> Reviewed-by: Chia-I Wu <olvaffe@gmail.com>
© 2016 - 2025 Red Hat, Inc.