CVE-2026-97900: drm/drm_exec: fix up contended obj when num_objects is 0
In the Linux kernel, the following vulnerability has been resolved:
drm/drmexec: fix up contended obj when numobjects is 0
drmexecpreparearray() silently returns success without calling drmexeclockcontended() when numobjects is zero. This breaks the invariant upheld by drmexeclockobj(), where every entry point into the locking sequence must first attempt to lock any previously contended object before proceeding.
Drivers that chain multiple drmexecpreparearray() calls per drmexecuntilalllocked() 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 drmexecretryoncontention() 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 drmexecpreparearray() call drmexeclockcontended() directly when numobjects is zero, so a pending contended object dont loop infinitely.
Affected Software
Event History
Frequently Asked Questions
What conditions are required to trigger the infinite loop?
A DRM driver must chain multiple drm_exec_prepare_array() calls within a drm_exec_until_all_locked() iteration, with an empty array passed before a non-empty array. Lock contention must occur while preparing the non-empty array, leaving a contended object pending for the retry.
Which workloads are most likely to be exposed?
The issue affects driver paths that prepare separate buffer-object arrays and can supply an empty array for one of them. The description identifies amdgpu userq signal/wait ioctls as an example.
What is the practical impact of a successful trigger?
The retry path can spin forever because the empty-array preparation does not resolve the previously contended object. This can prevent the locking loop from making progress.
How does the fix prevent the loop?
The fix makes drm_exec_prepare_array() call drm_exec_lock_contended() when num_objects is zero. This resolves any pending contended object before the retry logic can restart the loop.