Cloudanix VulnDB

CVE-2026-98521

None

CVSS

—

EPSS

0.2%

Published

Oct 18, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A flaw in Linux graphics handling can cause the computer to freeze when certain display operations happen at the same time as memory cleanup.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
Moderate
Impact
Denial Of Service
Component
OS kernel
Class
Race Condition
Remediation
Patch
Effort
Medium
Patch risk
Low

What it actually does

Incorrect RCU teardown order in i915 GEM object handling allows dma_resv_for_each_fence_unlocked to encounter a destroyed dma_fence without a replacement list, causing the iteration to restart indefinitely and enter an endless loop.

Why it matters to the business

Graphics-intensive workloads or user sessions can trigger kernel-level hangs on affected Linux systems, leading to system unresponsiveness, disrupted rendering, and the need for reboots or restarts that interrupt operations.

How an attack unfolds

A local attacker with access to the graphics device opens a GEM object, initiates i915_gem_busy_ioctl while concurrently destroying the object under RCU read-side lock, causing the fence iteration to loop forever when it detects the destroyed fence with no new list installed.

How to fix it

Apply the upstream fix that ensures dma_fence references are dropped only after the RCU grace period; rebuild and deploy an updated Linux kernel containing commit 5113479556025093bf8133bb2dcaa33be2d50921 or equivalent backport.

How to confirm the fix worked

Confirm the kernel source contains the corrected teardown ordering, run targeted stress tests exercising i915_gem_busy_ioctl concurrent with object destruction, and verify absence of CPU spin in the fence iteration path.

Typical attack path

  1. Obtain local user access on a system using i915 graphics
  2. Allocate or reference a GEM buffer object via ioctl
  3. Invoke busy ioctl to start fence iteration under RCU
  4. Trigger concurrent destruction of the GEM object
  5. Observe indefinite loop in dma_resv_for_each_fence_unlocked

How to detect it

Review kernel logs for repeated entries or watchdog triggers around drm/i915 fence handling; inspect RCU-related stalls or soft lockup messages on graphics workloads; correlate with processes using DRI or GEM ioctls.

What your security team should do

  • Prioritize kernel upgrade on all systems exposing i915 devices within the next patch cycle
  • Monitor upstream stable branches for the backported fix
  • Restrict unprivileged access to /dev/dri devices where feasible until patched

The record

In the Linux kernel, the following vulnerability has been resolved: drm/i915: fix incorrect RCU teardown order i915_gem_busy_ioctl uses dma_resv_for_each_fence_unlocked() to iterate over the fences in an GEM object without holding a reference but only the RCU read side lock. What can happen here is that the GEM object is destroyed concurrently while i915_gem_busy_ioctl is still running. This won't free the GEM objects memory, but still drops all the dma_fence references. Now when dma_resv_for_each_fence_unlocked() sees a destroyed dma_fence it assumes that a new fence list was installed and re-starts the loop. But in the case of a destroyed GEM object a new fence list is never installed, only the old one freed and therefore the iteration never finishes resulting in an endless loop. The solution is to drop the fence references only after the RCU grace period. The fixes tag is not necessary the patch introducing the problem, but the one making it so worse that we need to address it. This problem was pointed out by Sashiko-bot. (cherry picked from commit 5113479556025093bf8133bb2dcaa33be2d50921)

Affected packages

Ecosystem Package Introduced Fixed