Description
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.
Published: 2026-10-18
Score: n/a
EPSS: n/a
KEV: No
Impact: Resource Leak leading to possible denial of service
Action: Apply Patch
AI Analysis

Impact

The vulnerability arises in the Linux kernel’s virtio GPU driver, where an error in drm_gem_handle_create() causes an object reference not to be released. This leaves shared memory pages, scatter-gather tables, and GPU object structures unreleased, resulting in a memory and resource leak on the host. Once the host‑side resource and identifier are also not cleaned up, repeated failures can exhaust memory, degrade performance, or cause a denial of service. The flaw pertains to improper reference counting and resource cleanup – a classic resource‑leak weakness.

Affected Systems

Linux kernel deployments that expose the virtio‑GPU (i.e., virtual machines or containers utilizing GPU passthrough or virtual GPU devices). Versions prior to the fix contained the issue; no specific version list is supplied, so all kernels before the commit that introduced the patch are considered affected.

Risk and Exploitability

The flaw is a kernel-level resource leak; it does not enable code execution or privilege escalation directly, but it can be exploited by repeatedly triggering the failure path to drain system memory and disrupt services. No EPSS score is available, and the vulnerability is not listed in the CISA KEV catalog, so exploitation probability and immediate threat level are uncertain. However, because the defect occurs within the kernel’s graphics subsystem, it is potentially exploitable on systems that actively use virtio‑GPU devices, warranting patching or mitigation.

Generated by OpenCVE AI on October 18, 2026 at 18:29 UTC.

Remediation

No solution or workaround provided in the CVE record.

OpenCVE Recommended Actions

  • Apply the kernel patch that fixes the missing reference release, as referenced in the provided commit URLs (e.g., commit 13423a058187c2039aa8cb235c916be4477221b7).
  • If an immediate kernel update is not possible, limit or disable virtio‑GPU usage on the affected host until the patch is applied to prevent continued resource leakage.
  • Monitor virtual GPU memory consumption and system stability; if memory pressure increases unexpectedly, investigate the GPU driver for leaks.

Generated by OpenCVE AI on October 18, 2026 at 18:29 UTC.

Tracking

Sign in to view the affected projects.

Advisories

No advisories yet.

History

Sun, 18 Oct 2026 18:45:00 +0000

Type Values Removed Values Added
Weaknesses CWE-917

Sun, 18 Oct 2026 15:30:00 +0000

Type Values Removed Values Added
Description 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.
Title drm/virtio: fix object leak when drm_gem_handle_create() fails
First Time appeared Linux
Linux linux Kernel
CPEs cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
Vendors & Products Linux
Linux linux Kernel
References

Subscriptions

Linux Linux Kernel
cve-icon MITRE

Status: PUBLISHED

Assigner: Linux

Published:

Updated: 2026-10-18T15:19:24.250Z

Reserved: 2026-09-25T10:25:14.360Z

Link: CVE-2026-98609

cve-icon Vulnrichment

No data.

cve-icon NVD

Status : Received

Published: 2026-10-18T16:17:13.677

Modified: 2026-10-18T16:17:13.677

Link: CVE-2026-98609

cve-icon Redhat

No data.

cve-icon OpenCVE Enrichment

Updated: 2026-10-18T18:30:14Z

Weaknesses
  • CWE-917

    Improper Neutralization of Special Elements used in an Expression Language Statement ('Expression Language Injection')