CVE-2026-72095
HighCVSS 7.8Exploitation Probability (EPSS)
Low risk6th percentile - higher than 6% of all known CVEs
Summary
In the Linux kernel, the dma_fence_dedup_array() function returns 1 when called with a count of 0, which contradicts the documentation and may lead to dereferencing an uninitialized pointer in amdgpu_userq_wait_*(). The fix makes the function return 0 for an empty array.
Risk Assessment
The risk includes potential dereference of uninitialized memory, which could lead to system crashes or incorrect behavior of graphics drivers.
Recommendation
It is recommended to update the Linux kernel to a version with the fix that ensures correct behavior for zero count input.
Original NVD description (English source)
In the Linux kernel, the following vulnerability has been resolved: dma-fence: Make dma_fence_dedup_array() robust against 0-count input dma_fence_dedup_array() returns 1 when called with num_fences == 0: the for-loop body never executes, j stays at 0, and the final `return ++j` yields 1. This contradicts both the kernel-doc ("Return: Number of unique fences remaining in the array") and the natural expectation that 0 input gives 0 output. The caller __dma_fence_unwrap_merge() bails out via the `if (count == 0 || count == 1)` fast path and so is save. But amdgpu_userq_wait_*() could reach the dedup call with a zero local count and dereference an uninitialized fence slot in the array. Make the contract match the documentation by returning 0 early. This also skips an unnecessary sort() call on an empty array.