The bug in the Intel i915 DRM driver occurs when i915_gem_busy_ioctl iterates over DMA fences without holding a proper reference to the GEM object. If the GEM object is destroyed concurrently, the routine drops all pending dma_fence references but still runs inside the RCU read‑side critical section. The iterator then encounters a freed fence, incorrectly assumes a new fence list has been installed, and restarts the loop. Because no new list is ever installed for a destroyed object, the loop never terminates, causing an infinite CPU‑bound cycle in the kernel. For an attacker, this manifests as a local denial‑of‑service: a single crafted ioctl can consume kernel CPU, potentially exhausting system resources and hanging the invoking process. The primary weakness reflected here is a race condition and an improper synchronization between resource deallocation and use.

All Linux kernel builds that ship without the fix for the i915 DRM driver are affected. The link to the commit that resolves the issue (5113479556025093bf8133bb2dcaa33be2d50921) indicates that any kernel version prior to that commit is vulnerable. Since the CNA vendor list only lists the Linux kernel generically, affected systems include any distribution or custom kernel that uses the buggy i915 driver until a patched kernel is deployed.

No CVSS score is published and the EPSS value is unknown, yet the flaw is not listed in the CISA KEV catalog. Nonetheless, because it requires local access to perform the damaging ioctl and does not rely on higher privileges, any user that can open a DRM device can trigger the endless loop. The lack of an explicit exploitation rate in the data suggests that the vulnerability is not widely known or actively exploited at this time, but the potential for resource exhaustion and kernel hang makes the risk significant for compromised hosts. Administrators should consider immediate patching or mitigating controls until the fix is applied.