[PATCH] drm/vmwgfx: Fix use-after-free race in vmw_dumb_create()

[PATCH] drm/vmwgfx: Fix use-after-free race in vmw_dumb_create()

[Jayapal Ashwin Nair]

vmw_dumb_create(), called from DRM_IOCTL_MODE_CREATE_DUMB, drops its
extra GEM reference on the vbo before it reads vbo->dumb_surface and
clears the user surface's refcount_release. After that put, the only
reference left is held by the GEM handle, which is already visible to
userspace. A concurrent DRM_IOCTL_GEM_CLOSE on that handle can drop it
and free the vbo (and the dumb surface) while vmw_dumb_create() is
still using them:

  CPU0 (DRM_IOCTL_MODE_CREATE_DUMB)      CPU1 (DRM_IOCTL_GEM_CLOSE)
  vmw_dumb_create()
   vmw_gb_surface_define_ext_ioctl()
     /* vbo refcount == 2 */
   drm_gem_object_put(&vbo->tbo.base)
     /* vbo refcount == 1 */
                                         drm_gem_close_ioctl()
                                          drm_gem_handle_delete()
                                           drm_gem_object_release_handle()
                                            drm_gem_object_handle_put_unlocked()
                                             drm_gem_object_put()
                                              /* vbo refcount == 0 */
                                              vmw_gem_object_free()
                                               ttm_bo_fini()
                                                vmw_bo_free()
                                                 vmw_surface_unreference()
                                                 kfree(vbo)
   usurf = container_of(vbo->dumb_surface, ...)  /* UAF read */
   usurf->prime.base.refcount_release = NULL     /* UAF write */

Move drm_gem_object_put() after the last access to the vbo.

Fixes: f42c09e614f1 ("drm/vmwgfx: Fix dumb buffer leak")
Signed-off-by: Jayapal Ashwin Nair <jayapalashwin.nair@amd.com>
---
 drivers/gpu/drm/vmwgfx/vmwgfx_surface.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_surface.c b/drivers/gpu/drm/vmwgfx/vmwgfx_surface.c
index bd0563741e89..2dfbd914bdef 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_surface.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_surface.c
@@ -2332,7 +2332,6 @@ int vmw_dumb_create(struct drm_file *file_priv,
 	vbo = res->guest_memory_bo;
 	vbo->is_dumb = true;
 	vbo->dumb_surface = vmw_res_to_srf(res);
-	drm_gem_object_put(&vbo->tbo.base);
 	/*
 	 * Unset the user surface dtor since this in not actually exposed
 	 * to userspace. The suface is owned via the dumb_buffer's GEM handle
@@ -2340,6 +2339,7 @@ int vmw_dumb_create(struct drm_file *file_priv,
 	struct vmw_user_surface *usurf = container_of(vbo->dumb_surface,
 						struct vmw_user_surface, srf);
 	usurf->prime.base.refcount_release = NULL;
+	drm_gem_object_put(&vbo->tbo.base);
 err:
 	if (res)
 		vmw_resource_unreference(&res);
-- 
2.53.0

Re: [PATCH] drm/vmwgfx: Fix use-after-free race in vmw_dumb_create()

[Maaz Mombasawala <maaz.mombasawala@broadcom.com>]

How is userspace able to see the gem handle to call DRM_IOCTL_GEM_CLOSE
on it before DRM_IOCTL_MODE_CREATE_DUMB has returned it?

-- 
Maaz Mombasawala <maaz.mombasawala@broadcom.com> 

Re: [PATCH] drm/vmwgfx: Fix use-after-free race in vmw_dumb_create()

[Nair, Jayapal Ashwin]

On 30-10-2026 06:59, Maaz Mombasawala <maaz.mombasawala@broadcom.com> wrote:
> How is userspace able to see the gem handle to call DRM_IOCTL_GEM_CLOSE
> on it before DRM_IOCTL_MODE_CREATE_DUMB has returned it?
> 
The handle is installed in file_priv->object_idr by
drm_gem_handle_create() inside vmw_gb_surface_define_ext_ioctl(), before
DRM_IOCTL_MODE_CREATE_DUMB returns it, and GEM handles are predictable:
idr_alloc() hands out the lowest free id starting at 1. On a freshly
opened fd the dumb buffer gets handle 1, so a second thread on the same
fd can spin on DRM_IOCTL_GEM_CLOSE(1), getting -EINVAL until the handle
appears. Once closed, id 1 is free again, so the race can be retried
indefinitely.

I tried this methodology and got a KASAN splat:

 BUG: KASAN: slab-use-after-free in vmw_dumb_create+0x705/0x850
   Read of size 8 at addr ffff88810fd5b2d0 by task poc/228
   ...
   Allocated by task 228:
    __kmalloc_cache_noprof+0x166/0x3b0
    vmw_bo_create+0xbc/0x660
    vmw_gem_object_create_with_handle+0xf9/0x190
    vmw_gb_surface_define_internal.constprop.0+0xe23/0x17c0
    vmw_dumb_create+0x415/0x850
   ...
   Freed by task 228:
    kfree+0x216/0x450
    vmw_bo_free+0x414/0x640
    ttm_bo_release+0x3bc/0x9a0
    vmw_dumb_create+0x6d9/0x850
   ...
   The buggy address belongs to the object at ffff88810fd5b000
    which belongs to the cache kmalloc-1k of size 1024
   The buggy address is located 720 bytes inside of
    freed 1024-byte region [ffff88810fd5b000, ffff88810fd5b400)
   ...
   BUG: unable to handle page fault for address: ffffffffffffffb0
   #PF: supervisor write access in kernel mode
   RIP: 0010:vmw_dumb_create+0x667/0x850
   R12: 0000000000000000
   Kernel panic - not syncing: Fatal exception

The read is vbo->dumb_surface (offset 0x2d0); it comes back NULL and the
subsequent usurf->prime.base.refcount_release = NULL store faults at
NULL - 0x50.

> --
> Maaz Mombasawala <maaz.mombasawala@broadcom.com>
>