CVE-2026-98607 in Linux
Summary
by MITRE • 10/18/2026
In the Linux kernel, the following vulnerability has been resolved:
drm/virtio: fix object leaks in virtio_gpu_resource_create_blob_ioctl()
virtio_gpu_resource_create_blob_ioctl() calls drm_gem_object_release() on both the virtio_gpu_resource_assign_uuid() and drm_gem_handle_create() error paths instead of dropping the reference it owns, so obj->funcs->free() never runs and the virtio_gpu_object, the resource id and the host-side resource are leaked.
Use drm_gem_object_put() instead.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 10/18/2026
The vulnerability identified in the Linux kernel's DRM virtual GPU driver involves a critical resource management flaw within the virtio_gpu_resource_create_blob_ioctl function. This specific ioctl handler is responsible for creating blob resources, which are typically used to transfer large binary data between userspace and the guest operating system via the VirtIO graphics protocol. The core technical issue stems from an incorrect API usage during error handling paths. Specifically, when either the assignment of a unique identifier or the creation of a GEM handle fails, the code erroneously invokes drm_gem_object_release instead of the appropriate reference counting function. This misstep bypasses the standard kernel object lifecycle management mechanisms designed to ensure proper cleanup and memory reclamation.
The operational consequence of this error is a persistent resource leak that degrades system stability over time. By calling drm_gem_object_release, which is intended for final teardown when an object's lifetime has definitively ended, the driver fails to decrement the reference count held by the current context. Consequently, the underlying virtio_gpu_object structure remains allocated in memory along with its associated resource identifier and host-side resources. Since the free callback function attached to the GEM object operations is never triggered, these allocations persist indefinitely until the system reboots or the process terminates abnormally. In a long-running virtualized environment, this accumulation of unreleased kernel objects can lead to significant memory pressure, potentially exhausting available kernel memory and causing broader system instability or denial of service conditions for other workloads running on the host or guest.
From a classification perspective, this flaw aligns with CWE-401, which describes a missing release of memory after effective usage, specifically manifesting as a resource leak in non-garbage collected environments like the Linux kernel. The vulnerability also relates to improper handling of reference counts, a common source of bugs in systems programming where explicit ownership semantics must be strictly maintained. In terms of attack vectors and defensive mapping, this issue does not directly facilitate remote code execution but represents an availability risk through resource exhaustion. It can be contextualized within the ATT&CK framework under techniques related to impact or defense evasion if exploited systematically by a malicious guest user intenting to degrade host performance via memory consumption attacks against kernel subsystems.
The remediation for this vulnerability requires replacing the erroneous drm_gem_object_release calls with drm_gem_object_put in both error paths of the virtio_gpu_resource_create_blob_ioctl function. The put function correctly decrements the reference count and only triggers the actual dealmentation logic when the final reference is dropped, ensuring that obj->funcs->free() executes as intended during cleanup sequences. This change restores compliance with standard kernel object management practices, guaranteeing that allocated resources are properly returned to the system pool upon failure or completion of the ioctl operation. System administrators should ensure their kernels are updated to include this patch, particularly in environments where untrusted userspace applications interact frequently with virtual GPU drivers, thereby mitigating the risk of gradual resource depletion and maintaining long-term operational integrity of the virtualization stack.