In the Linux kernel, the following vulnerability has been resolved:

drm/v3d: Reject empty multisync extension to prevent infinite loop

v3dgetextensions() walks a userspace-provided singly-linked list of ioctl extensions without any bound on the chain length. A local user can craft a self-referential extension (ext->next == &ext) with zero insynccount and outsynccount, which bypasses the existing duplicate- extension guard:

if (se->insynccount || se->outsynccount) return -EINVAL;

The guard never fires because v3dgetmultisyncpostdeps() returns immediately when count is zero, leaving both fields at zero on every iteration. The result is an infinite loop in kernel context, blocking the calling thread and pegging a CPU core indefinitely.

Fix this by rejecting a multisync extension where both insynccount and outsynccount are zero in v3dgetmultisyncsubmitdeps(). An empty multisync carries no synchronization information and serves no useful purpose, so returning -EINVAL for such an extension is the correct defense against this attack vector.

In the Linux kernel, the following vulnerability has been resolved:

drm/v3d: Skip CSD when it has zeroed workgroups

A compute shader dispatch encodes its workgroup counts in the CFG0..CFG2 registers. Kicking off a dispatch with a zero count in any of the three dimensions is invalid. First, the hardware will process 0 as 65536, while the user-space driver exposes a maximum of 65535. Over that, a submission with a zeroed workgroup dimension should be a no-op.

These zeroed counts can reach the dispatch path through an indirect CSD job, whose workgroup counts are only known once the indirect buffer is read and may legitimately be zero, but such scenario should only result in a no-op.

Overwrite the indirect CSD job workgroup counts with the indirect BO ones, even if they are zeroed, and don't submit the job to the hardware when any of the workgroup counts is zero, so the job completes immediately instead of running the shader.

In the Linux kernel, the following vulnerability has been resolved:

drm/v3d: Fix vaddr leak when indirect CSD has zeroed workgroups

v3drewritecsdjobwgcountsfromindirect() maps both the indirect buffer and the workgroup buffer and is expected to release them before returning. When any of the workgroup counts read from the buffer is zero, the function bailed out early and skipped the cleanup, leaking the vaddr mappings of both BOs.

Jump to the cleanup path instead of returning directly, so the mappings are always dropped.