Cloudanix VulnDB

CVE-2026-98509

None

CVSS

—

EPSS

0.2%

Published

Oct 18, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A bug in the code that handles graphics commands for virtual machines can slowly use up memory when certain operations fail, potentially making systems less responsive over time.

Exploitation
Local Privilege
Attacker needs
Low Privilege
Complexity
Moderate
Impact
Denial Of Service
Component
OS kernel
Class
Memory Corruption
Remediation
Patch
Effort
Low
Patch risk
Low

What it actually does

Memory leak of unreferenced DRM event allocations in virtio_gpu_execbuffer_ioctl error paths when drm_event_reserve_init succeeds but later processing fails, leaving the event orphaned because virtio_gpu_cleanup_submit drops the fence without cancellation and drm_events_release does not free it.

Why it matters to the business

Gradual memory exhaustion on Linux systems using virtio GPU in virtualized environments, potentially leading to degraded performance or denial of service after repeated failed graphics submission attempts.

How an attack unfolds

An attacker with local access issues repeated virtio GPU execbuffer ioctls that select a polled ring but fail early validation on BO handles or sync objects; each failure leaks a kernel allocation that persists until reboot because no driver path ever emits or frees the event.

How to fix it

Apply the upstream kernel patch that cancels and frees the reserved DRM event on all execbuffer error paths before dropping the fence, then rebuild and deploy the fixed kernel image; monitor vendor backports for distribution-specific updates.

How to confirm the fix worked

Confirm the patched kernel no longer leaks objects under Syzkaller-style fuzzing of virtio_gpu_execbuffer_ioctl with invalid arguments; inspect dmesg or kmemleak reports for absence of unreferenced virtio_gpu_fence_event_create allocations after error-path triggers.

Typical attack path

  1. Obtain local unprivileged access to a system with virtio GPU driver loaded
  2. Open a DRM device file and enable polling on a command ring
  3. Invoke virtio_gpu_execbuffer_ioctl with invalid BO handles or sync objects that trigger argument validation failures
  4. Repeat to accumulate leaked DRM event structures until memory pressure occurs

How to detect it

Review kernel logs and kmemleak reports for repeated allocations from virtio_gpu_fence_event_create and virtio_gpu_init_submit without matching drm_send_event calls; correlate with high-frequency failed DRM ioctls from untrusted processes.

What your security team should do

  • Prioritize kernel updates on all virtualization hosts and guests using virtio GPU within the next maintenance window
  • Restrict unprivileged access to /dev/dri devices where feasible until patched
  • Enable kernel memory leak detectors in test and staging environments to validate the fix

The record

In the Linux kernel, the following vulnerability has been resolved: drm/virtio: fix memory leak of fence event on execbuffer failure virtio_gpu_execbuffer_ioctl() reserves a DRM event with drm_event_reserve_init() when VIRTGPU_EXECBUF_RING_IDX selects a ring that userspace has enabled polling for. virtio_gpu_init_submit() does this before the BO handles, the command buffer, the syncobj arrays and the in-fence are processed, so every later error path runs with the event already pending, including plain argument validation failures such as an invalid bo_handle or an in-syncobj that carries no fence. On those paths, virtio_gpu_cleanup_submit() drops the out-fence without cancelling the event. The fence is freed without ever having been emitted, taking the only driver-side pointer to the event with it. Closing the DRM file does not help. drm_events_release() unlinks pending events but deliberately leaves the freeing to the driver's later drm_send_event(), which never runs for an orphaned event, so the allocation is leaked permanently. Found when fuzzing the virtio driver with Syzkaller: BUG: memory leak unreferenced object 0xffff88802c176e80 (size 96): comm "syz.1.367", pid 10561, jiffies 4294960122 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ c8 6e 17 2c 80 88 ff ff 00 00 00 00 00 00 00 00 .n.,............ backtrace (crc e1973c6b): kmemleak_alloc_recursive include/linux/kmemleak.h:44 [inline] slab_post_alloc_hook mm/slub.c:4597 [inline] slab_alloc_node mm/slub.c:4917 [inline] __kmalloc_cache_noprof+0x49d/0x6f0 mm/slub.c:5485 _kmalloc_noprof include/linux/slab.h:988 [inline] _kzalloc_noprof include/linux/slab.h:1309 [inline] virtio_gpu_fence_event_create drivers/gpu/drm/virtio/virtgpu_submit.c:282 [inline] virtio_gpu_init_submit drivers/gpu/drm/virtio/virtgpu_submit.c:398 [inline] virtio_gpu_execbuffer_ioctl+0xbbf/0x1aa0 drivers/gpu/drm/virtio/virtgpu_submit.c:505 drm_ioctl_kernel+0x1f4/0x3e0 drivers/gpu/drm/drm_ioctl.c:817 drm_ioctl+0x5f4/0xc70 drivers/gpu/drm/drm_ioctl.c:914 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:597 [inline] __se_sys_ioctl fs/ioctl.c:583 [inline] __x64_sys_ioctl+0x18e/0x210 fs/ioctl.c:583 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x116/0x800 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f Fix by cancelling and freeing the DRM event on the execbuffer error path before dropping the fence. Clear the fence's event pointer after cancellation so it does not retain a dangling pointer.

Affected packages

Ecosystem Package Introduced Fixed