Live › vulnerability › CVE-2026-98606
Go to dashboardWhen creating a virtio GPU VRAM object fails, the Linux kernel frees the object while it is still linked into the device's offset manager, so later lookups walk freed memory. The sources do not state what an attacker can do with this beyond a use-after-free in the kernel.
Summary written from the sources below. Check the originals before acting.
First seen by InfraStack 2026-10-23 21:57 UTC. All times on this page are UTC.
Systems running a Linux kernel with the virtio-gpu DRM driver, typically virtual machines using virtio-gpu for graphics. The sources do not say which kernel versions are fixed or affected.
No product ranges from the sources yet.
Each row is the first time that source carried this signal. The analyst’s rows are its own findings.
In the Linux kernel, the following vulnerability has been resolved:
drm/virtio: release the GEM object on virtio_gpu_vram_create() errors
virtio_gpu_vram_create() frees the object with a bare kfree(vram) on both error paths after drm_gem_private_object_init() has run, and on the second one after drm_gem_create_mmap_offset() has linked obj->vma_node into the device's VMA offset manager. The freed object stays in that interval tree, so a later lookup or insertion walks freed memory, and the dma_resv and gpuva lock are never destroyed.
Call drm_gem_object_release() before kfree() on both paths.
This page as .md · .json · in your agent: get_signal("CVE-2026-98606")
NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.