CVE-2026-97900 in Linux
Summary
by MITRE • 09/25/2026
In the Linux kernel, the following vulnerability has been resolved:
drm/drm_exec: fix up contended obj when num_objects is 0
drm_exec_prepare_array() silently returns success without calling drm_exec_lock_contended() when num_objects is zero. This breaks the invariant upheld by drm_exec_lock_obj(), where every entry point into the locking sequence must first attempt to lock any previously contended object before proceeding.
Drivers that chain multiple drm_exec_prepare_array() calls per drm_exec_until_all_locked() iteration (e.g. amdgpu's userq signal/wait ioctls, which prepare separate read and write BO arrays) can pass an empty array for one of the two calls. If contention is hit while preparing the non-empty array, exec->contended is set and the loop retries; on retry, the empty-array call preceding it is a no-op that never clears exec->contended, so drm_exec_retry_on_contention() immediately jumps back to the top of the loop without ever reaching the call that would resolve the contention. This spins forever.
Fix it by having drm_exec_prepare_array() call drm_exec_lock_contended() directly when num_objects is zero, so a pending contended object dont loop infinitely.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 09/25/2026
The Linux kernel's Direct Rendering Manager subsystem contains a logic flaw within the drm_exec execution framework that can lead to an infinite spin condition under specific contention scenarios. This vulnerability arises from an inconsistency in how empty object arrays are handled during the locking sequence for buffer objects. Specifically, the function drm_exec_prepare_array is designed to prepare and lock graphics buffer objects required for command submission or other operations. However, when this function receives a num_objects parameter of zero, it silently returns success without invoking the critical helper function drm_exec_lock_contended. This behavior violates a fundamental invariant maintained by the locking mechanism, which dictates that every entry point into the sequence must first attempt to resolve any previously identified contended objects before proceeding with new operations.
The operational impact becomes apparent in drivers such as amdgpu, particularly when handling user queue signal and wait ioctls. These operations often involve chaining multiple calls to drm_exec_prepare_array within a single iteration of the drm_exec_until_all_locked loop. For instance, one call may prepare an array for read access while another prepares an array for write access. It is possible for one of these arrays to be empty, resulting in num_objects being zero for that specific call. If contention occurs during the preparation of the non-empty array, the system sets a flag indicating a contended object and retries the loop. On subsequent iterations, the call corresponding to the empty array executes as a no-op due to the bug, failing to clear or resolve the pending contention state. Consequently, the retry logic immediately jumps back to the start of the loop without ever reaching the code path responsible for resolving the actual contention, causing the kernel thread to spin indefinitely and consume CPU resources while blocking other operations.
This flaw is categorized under CWE-835, which describes a loop that never terminates due to incorrect control flow or state management. From an offensive security perspective, this vulnerability aligns with MITRE ATT&CK technique T1499, specifically Endpoint Denial of Service via resource exhaustion. An attacker who can trigger these specific ioctl paths under high contention conditions could induce a denial of service by exhausting CPU cycles on the affected system. The issue highlights the importance of maintaining strict invariants across all code paths within complex locking mechanisms to prevent state desynchronization that leads to infinite loops.
To mitigate this vulnerability, the kernel developers have updated drm_exec_prepare_array to explicitly call drm_exec_lock_contended even when num_objects is zero. This ensures that any pending contended objects are properly resolved regardless of whether new buffer objects are being prepared in the same step. System administrators and users should apply the latest available kernel updates for their distributions to patch this issue. For developers maintaining custom kernels, backporting the fix from upstream Linux stable repositories is recommended. Regular auditing of locking logic in graphics drivers can help identify similar invariant violations before they manifest as denial-of-service conditions in production environments.