CVE-2026-98609

In the Linux kernel, the following vulnerability has been resolved:

drm/virtio: fix object leak when drm_gem_handle_create() fails

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.