CVE-2026-98606

What it actually does

Use-after-free in virtio_gpu_vram_create: bare kfree(vram) after drm_gem_private_object_init and drm_gem_create_mmap_offset leaves the object in the VMA offset interval tree, allowing subsequent lookup/insertion to dereference freed memory while dma_resv and gpuva locks are never destroyed.

Why it matters to the business

Kernel memory corruption or crashes in virtualized Linux guests using VirtIO GPU, potentially leading to guest denial-of-service or local privilege escalation; the flaw is newly public so exposure is currently low but will rise as patches propagate.

How an attack unfolds

An attacker with access to trigger VRAM object creation in the virtio-gpu driver forces one of the error paths, causing the object to be freed while still referenced by the device's VMA manager; later operations on that node walk freed memory, enabling corruption or control-flow hijacking.

How to fix it

Update the Linux kernel to a version containing the fix that calls drm_gem_object_release before kfree on both error paths in virtio_gpu_vram_create; rebuild and reboot affected systems.

How to confirm the fix worked

Inspect the drm/virtio/virtio_gpu_object.c source for the presence of drm_gem_object_release calls before kfree in virtio_gpu_vram_create error paths; verify running kernel version against upstream commit that resolved the issue.

Typical attack path

1. Obtain local code execution or trigger graphics operations inside a VirtIO GPU guest
2. Force virtio_gpu_vram_create to take an error path after GEM initialization and VMA offset registration
3. Trigger subsequent VMA lookup or insertion to dereference the freed object
4. Leverage resulting memory corruption for privilege escalation or denial of service

How to detect it

Review kernel logs for use-after-free warnings or crashes referencing virtio_gpu or drm_gem structures; examine core dumps or KASAN reports showing accesses to freed VMA nodes or drm_gem objects in the virtio driver.

What your security team should do

• Prioritize kernel updates for all systems exposing VirtIO GPU devices
• Monitor upstream stable and distribution kernels for the backported fix
• Restrict untrusted guest access to VirtIO GPU until patched