CVE-2026-97900

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.