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 - 2026 Red Hat, Inc.