Cloudanix VulnDB

CVE-2026-98319

None

CVSS

—

EPSS

0.2%

Published

Oct 6, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A bug in the Linux graphics driver can slowly leak memory during certain screen-update operations, eventually making the system unstable.

Exploitation
Local Privilege
Attacker needs
Local User
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 drm_pending_vblank_event objects in the Linux kernel DRM subsystem when an out_fence_ptr is supplied without DRM_MODE_PAGE_FLIP_EVENT and a subsequent failure occurs in drm_event_reserve_init or setup_out_fence, bypassing the normal release path in complete_signaling.

Why it matters to the business

Gradual kernel memory exhaustion on Linux systems that perform DRM page-flip operations, which can degrade graphics performance, trigger OOM conditions, or cause system instability in graphics workloads over extended uptime.

How an attack unfolds

An attacker with local access triggers repeated DRM_IOCTL_MODE_PAGE_FLIP ioctls that supply an out_fence_ptr but omit the page-flip event flag, then induces allocation pressure or other failures inside prepare_signaling so the reserved event is never freed.

How to fix it

Apply the upstream fix that calls drm_event_cancel_free and clears crtc_state->event on the error path inside prepare_signaling; rebuild and reboot to the patched kernel.

How to confirm the fix worked

Confirm the patch is present by inspecting drm_atomic.c or drm_crtc.c around prepare_signaling for the drm_event_cancel_free call; run targeted DRM page-flip test cases that previously triggered the leak and verify no growth in slab objects of type drm_pending_vblank_event.

Typical attack path

  1. Obtain a DRM master file descriptor on a Linux system
  2. Issue page-flip ioctls with out_fence_ptr set but without DRM_MODE_PAGE_FLIP_EVENT
  3. Force allocation or reservation failures inside the kernel's prepare_signaling path
  4. Repeat to accumulate unreleased drm_pending_vblank_event structures

How to detect it

Inspect kernel logs for repeated DRM page-flip failures; correlate with slabinfo or /proc/meminfo growth in the drm_pending_vblank_event cache; review audit logs for unusual ioctl patterns on /dev/dri/card* devices.

What your security team should do

  • Patch all Linux kernels to the fixed version as soon as vendor packages are available
  • Monitor kernel slab allocator statistics for unexpected growth in drm_pending_vblank_event objects
  • Restrict unprivileged access to DRM devices via device permissions or namespaces where feasible

The record

In the Linux kernel, the following vulnerability has been resolved: drm: Fix drm_pending_vblank_event leak in error path for out_fence_ptr When an out_fence_ptr is provided but DRM_MODE_PAGE_FLIP_EVENT is not set, a drm_pending_vblank_event will be allocated. If later, there is an allocation failure or another failure at setup_out_fence(), that event will not have base.fence set and it will not be released at complete_signaling(). Release the event and set crtc_state->event to NULL just like in the DRM_MODE_PAGE_FLIP_EVENT case when there is a failure at drm_event_reserve_init(). That is, prepare_signaling() releases the event and there is nothing to be done at complete_signaling(). Use drm_event_cancel_free() as that will also undo drm_event_reserve_init() in case it has been called.

Affected packages

Ecosystem Package Introduced Fixed