CVE-2026-98509 in Linux
Summary
by MITRE • 10/18/2026
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.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 10/19/2026
The Linux kernel contains a memory leak vulnerability within the virtio GPU driver, specifically in the execution buffer ioctl handling logic. This flaw arises from an improper resource management sequence during error conditions when userspace requests polling on specific rings. The function virtio_gpu_execbuffer_ioctl initiates the process by reserving a DRM event using drm_event_reserve_init if the selected ring supports user-space polling. However, this reservation occurs before critical validation steps such as processing buffer object handles, command buffers, synchronization objects, and input fences are completed. Consequently, any subsequent failure in these downstream operations leaves the reserved event in an inconsistent state where it is neither properly emitted nor correctly cleaned up.
The core technical flaw lies in how error paths handle this prematurely allocated resource. When virtio_gpu_init_submit encounters errors such as invalid buffer object handles or synchronization objects lacking associated fences, it invokes virtio_gpu_cleanup_submit to release resources. This cleanup routine drops the output fence but fails to cancel or free the previously reserved DRM event. Since the fence is freed without ever being emitted, the only driver-side reference to the event is lost. Standard kernel mechanisms for releasing events do not resolve this issue because drm_events_release unlinks pending events but relies on the driver's subsequent call to drm_send_event to actually free the memory allocation. Because that send operation never executes for orphaned events resulting from early failures, the allocated memory remains unreferenced and permanently leaked in kernel space.
This vulnerability was identified through fuzzing of the virtio driver using Syzkaller, which triggered a kmemleak bug report indicating an unreferenced object of size ninety-six bytes. The stack trace confirms that the allocation originates from virtio_gpu_fence_event_create called during submit initialization and ultimately stems from the ioctl entry point. From a security perspective, this represents a denial-of-service vector where unprivileged userspace processes can exhaust kernel memory by repeatedly triggering these error paths. Over time, such leaks degrade system stability and performance, potentially leading to out-of-memory conditions or system crashes depending on workload intensity and available resources.
The remediation involves modifying the execbuffer error path to explicitly cancel and free the DRM event before dropping the fence reference. Crucially, the fix also requires clearing the fence's event pointer after cancellation to prevent dangling pointer dereferences that could lead to use-after-free vulnerabilities or further memory corruption. This ensures proper lifecycle management of kernel objects even when validation fails early in the processing pipeline.
From a classification standpoint, this vulnerability aligns with CWE-401 which describes missing release of memory after effective usage leading to resource exhaustion. In terms of attack patterns, it relates to ATT&CK technique T1529 involving system shutdown or reboot via denial-of-service conditions caused by resource depletion in kernel subsystems. Mitigation strategies include applying the provided patch that corrects the cleanup sequence and ensuring regular updates to the Linux kernel on systems utilizing virtio GPU drivers. Administrators should monitor for signs of memory pressure or kmemleak warnings as indicators of potential exploitation attempts targeting this specific code path.