* [PATCH] drm/virtio: fix object leak when drm_gem_handle_create() fails
@ 2026-08-15 6:16 Junrui Luo via B4 Relay
2026-09-07 14:07 ` Dmitry Osipenko
0 siblings, 1 reply; 3+ messages in thread
From: Junrui Luo via B4 Relay @ 2026-08-15 6:16 UTC (permalink / raw)
To: David Airlie, Gerd Hoffmann, Dmitry Osipenko, Gurchetan Singh,
Chia-I Wu, Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
Simona Vetter, Dave Airlie, Michael S. Tsirkin
Cc: dri-devel, virtualization, linux-kernel, Yuhao Jiang, Junrui Luo
From: Junrui Luo <moonafterrain@outlook.com>
virtio_gpu_gem_create() owns the reference taken by
virtio_gpu_object_create(). On the drm_gem_handle_create() error path it
calls drm_gem_object_release() instead of dropping that reference.
drm_gem_object_release() is the inverse of drm_gem_object_init() and does
not touch the reference count or call obj->funcs->free(), so it is only
correct as the last step of a destructor, as in
virtio_gpu_cleanup_object(). Using it here leaves the bo at refcount 1
with no remaining reference, so virtio_gpu_free_object() never runs and
the shmem pages, sg table and virtio_gpu_object are leaked. Since
virtio_gpu_object_create() has already set bo->created,
VIRTIO_GPU_CMD_RESOURCE_UNREF is not queued either, leaking the host-side
resource and the resource id.
drm_gem_handle_create_tail() drops the handle reference on all of its
internal error paths, so the caller only has to drop its own. Use
drm_gem_object_put(), matching the success path below.
Fixes: dc5698e80cf7 ("Add virtio gpu driver.")
Reported-by: Yuhao Jiang <danisjiang@gmail.com>
Assisted-by: Claude:claude-opus-5
Signed-off-by: Junrui Luo <moonafterrain@outlook.com>
---
drivers/gpu/drm/virtio/virtgpu_gem.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_gem.c b/drivers/gpu/drm/virtio/virtgpu_gem.c
index 66c3f6f74e9c..d2f0b8a3f172 100644
--- a/drivers/gpu/drm/virtio/virtgpu_gem.c
+++ b/drivers/gpu/drm/virtio/virtgpu_gem.c
@@ -45,7 +45,7 @@ static int virtio_gpu_gem_create(struct drm_file *file,
ret = drm_gem_handle_create(file, &obj->base.base, &handle);
if (ret) {
- drm_gem_object_release(&obj->base.base);
+ drm_gem_object_put(&obj->base.base);
return ret;
}
---
base-commit: f5bbbfec59b4e2fb7520a91de3df8a6174325d6a
change-id: 20260815-virtgpu-gem-create-leak-8620531cd3d8
Best regards,
--
Junrui Luo <moonafterrain@outlook.com>
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [PATCH] drm/virtio: fix object leak when drm_gem_handle_create() fails
2026-08-15 6:16 [PATCH] drm/virtio: fix object leak when drm_gem_handle_create() fails Junrui Luo via B4 Relay
@ 2026-09-07 14:07 ` Dmitry Osipenko
2026-09-08 3:32 ` Junrui Luo
0 siblings, 1 reply; 3+ messages in thread
From: Dmitry Osipenko @ 2026-09-07 14:07 UTC (permalink / raw)
To: moonafterrain, David Airlie, Gerd Hoffmann, Gurchetan Singh,
Chia-I Wu, Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
Simona Vetter, Dave Airlie, Michael S. Tsirkin
Cc: dri-devel, virtualization, linux-kernel, Yuhao Jiang
On 8/15/26 09:16, Junrui Luo via B4 Relay wrote:
> From: Junrui Luo <moonafterrain@outlook.com>
>
> virtio_gpu_gem_create() owns the reference taken by
> virtio_gpu_object_create(). On the drm_gem_handle_create() error path it
> calls drm_gem_object_release() instead of dropping that reference.
>
> drm_gem_object_release() is the inverse of drm_gem_object_init() and does
> not touch the reference count or call obj->funcs->free(), so it is only
> correct as the last step of a destructor, as in
> virtio_gpu_cleanup_object(). Using it here leaves the bo at refcount 1
> with no remaining reference, so virtio_gpu_free_object() never runs and
> the shmem pages, sg table and virtio_gpu_object are leaked. Since
> virtio_gpu_object_create() has already set bo->created,
> VIRTIO_GPU_CMD_RESOURCE_UNREF is not queued either, leaking the host-side
> resource and the resource id.
>
> drm_gem_handle_create_tail() drops the handle reference on all of its
> internal error paths, so the caller only has to drop its own. Use
> drm_gem_object_put(), matching the success path below.
>
> Fixes: dc5698e80cf7 ("Add virtio gpu driver.")
> Reported-by: Yuhao Jiang <danisjiang@gmail.com>
> Assisted-by: Claude:claude-opus-5
> Signed-off-by: Junrui Luo <moonafterrain@outlook.com>
> ---
> drivers/gpu/drm/virtio/virtgpu_gem.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/virtio/virtgpu_gem.c b/drivers/gpu/drm/virtio/virtgpu_gem.c
> index 66c3f6f74e9c..d2f0b8a3f172 100644
> --- a/drivers/gpu/drm/virtio/virtgpu_gem.c
> +++ b/drivers/gpu/drm/virtio/virtgpu_gem.c
> @@ -45,7 +45,7 @@ static int virtio_gpu_gem_create(struct drm_file *file,
>
> ret = drm_gem_handle_create(file, &obj->base.base, &handle);
> if (ret) {
> - drm_gem_object_release(&obj->base.base);
> + drm_gem_object_put(&obj->base.base);
> return ret;
> }
Could you please fix all other occurrences reported by bot in a v2?
--
Best regards,
Dmitry
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [PATCH] drm/virtio: fix object leak when drm_gem_handle_create() fails
2026-09-07 14:07 ` Dmitry Osipenko
@ 2026-09-08 3:32 ` Junrui Luo
0 siblings, 0 replies; 3+ messages in thread
From: Junrui Luo @ 2026-09-08 3:32 UTC (permalink / raw)
To: Dmitry Osipenko
Cc: David Airlie, Gerd Hoffmann, Gurchetan Singh, Chia-I Wu,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
Simona Vetter, Dave Airlie, Michael S. Tsirkin, dri-devel,
virtualization, linux-kernel, Yuhao Jiang
> On Sep 7, 2026, at 10:07 PM, Dmitry Osipenko <dmitry.osipenko@collabora.com> wrote:
>
> On 8/15/26 09:16, Junrui Luo via B4 Relay wrote:
>> From: Junrui Luo <moonafterrain@outlook.com>
>>
>> virtio_gpu_gem_create() owns the reference taken by
>> virtio_gpu_object_create(). On the drm_gem_handle_create() error path it
>> calls drm_gem_object_release() instead of dropping that reference.
>>
>> drm_gem_object_release() is the inverse of drm_gem_object_init() and does
>> not touch the reference count or call obj->funcs->free(), so it is only
>> correct as the last step of a destructor, as in
>> virtio_gpu_cleanup_object(). Using it here leaves the bo at refcount 1
>> with no remaining reference, so virtio_gpu_free_object() never runs and
>> the shmem pages, sg table and virtio_gpu_object are leaked. Since
>> virtio_gpu_object_create() has already set bo->created,
>> VIRTIO_GPU_CMD_RESOURCE_UNREF is not queued either, leaking the host-side
>> resource and the resource id.
>>
>> drm_gem_handle_create_tail() drops the handle reference on all of its
>> internal error paths, so the caller only has to drop its own. Use
>> drm_gem_object_put(), matching the success path below.
>>
>> Fixes: dc5698e80cf7 ("Add virtio gpu driver.")
>> Reported-by: Yuhao Jiang <danisjiang@gmail.com>
>> Assisted-by: Claude:claude-opus-5
>> Signed-off-by: Junrui Luo <moonafterrain@outlook.com>
>> ---
>> drivers/gpu/drm/virtio/virtgpu_gem.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/virtio/virtgpu_gem.c b/drivers/gpu/drm/virtio/virtgpu_gem.c
>> index 66c3f6f74e9c..d2f0b8a3f172 100644
>> --- a/drivers/gpu/drm/virtio/virtgpu_gem.c
>> +++ b/drivers/gpu/drm/virtio/virtgpu_gem.c
>> @@ -45,7 +45,7 @@ static int virtio_gpu_gem_create(struct drm_file *file,
>>
>> ret = drm_gem_handle_create(file, &obj->base.base, &handle);
>> if (ret) {
>> - drm_gem_object_release(&obj->base.base);
>> + drm_gem_object_put(&obj->base.base);
>> return ret;
>> }
> Could you please fix all other occurrences reported by bot in a v2?
Got it, I’ll work on it.
Thanks,
Junrui
>
> --
> Best regards,
> Dmitry
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2026-09-08 3:32 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2026-08-15 6:16 [PATCH] drm/virtio: fix object leak when drm_gem_handle_create() fails Junrui Luo via B4 Relay
2026-09-07 14:07 ` Dmitry Osipenko
2026-09-08 3:32 ` Junrui Luo
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®