---
id: "CVE-2026-98606"
kind: "vulnerability"
aliases: ["CVE-2026-98606"]
title: "Linux kernel: virtio-gpu error path frees GPU object still in use"
severity: "unknown"
cvss: null
epss: null
exploited: false
status: "open"
category: "infrastructure"
products: []
ecosystems: []
tags: ["infrastructure", "kernel", "linux", "virtio-gpu", "virtualization"]
not_affected_if: ["no-virtio-gpu"]
published_at: "2026-10-18T16:17:13+00:00"
first_seen_at: "2026-10-23T21:57:16+00:00"
updated_at: "2026-10-25T05:21:28+00:00"
sources: [{"source": "nvd", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-98606", "first_seen_at": "2026-10-23T21:57:16+00:00"}]
---

# Linux kernel: virtio-gpu error path frees GPU object still in use

When 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, check and fix written by a model from the sources; labelled as such._

## How to check

- unknown

## Fix

- unknown

## Timeline

- 2026-10-23T21:57:16+00:00 nvd https://nvd.nist.gov/vuln/detail/CVE-2026-98606

## From the sources

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.

---

_Free to read at a human pace. An API with keys and an MCP server are in preparation; early access: hello@infrastack.ai_