EUVD-2026-35124
GHSA-24m2-rchh-h2mx
Severity by source
AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Local ioctl interface requires device group membership (PR:L, AV:L); no complexity beyond crafting the struct (AC:L); pure CPU-peg DoS with no data or integrity impact (C:N/I:N/A:H).
Primary rating from NVD.
CVSS VectorNVD
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Lifecycle Timeline
5DescriptionNVD
In the Linux kernel, the following vulnerability has been resolved:
drm/v3d: Reject empty multisync extension to prevent infinite loop
v3d_get_extensions() 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 in_sync_count and out_sync_count, which bypasses the existing duplicate- extension guard:
if (se->in_sync_count || se->out_sync_count) return -EINVAL;
The guard never fires because v3d_get_multisync_post_deps() 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 in_sync_count and out_sync_count are zero in v3d_get_multisync_submit_deps(). 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.
AnalysisAI
Infinite loop denial-of-service in the Linux kernel's drm/v3d GPU driver allows a local low-privileged user to permanently peg a CPU core by submitting a crafted self-referential ioctl extension structure. The vulnerability exists in v3d_get_extensions(), which traverses a userspace-controlled linked list without bounding chain length; when both in_sync_count and out_sync_count are zero, the duplicate-extension guard silently passes on every iteration, trapping the kernel thread indefinitely. No public exploit or active exploitation has been identified at time of analysis; EPSS stands at 0.02%, consistent with the local-access-only attack surface.
Technical ContextAI
The drm/v3d subsystem provides Direct Rendering Manager support for the Broadcom VideoCore VI GPU, most notably present in Raspberry Pi 4 and similar SoC-based platforms. When userspace submits GPU jobs via ioctl, it can attach a singly-linked list of extension structures (multisync extensions) that carry synchronization fence counts. The function v3d_get_extensions() walks this list by following the ext->next pointer provided entirely from userspace. CWE-835 (Loop with Unreachable Exit Condition) is the root cause: the guard 'if (se->in_sync_count || se->out_sync_count) return -EINVAL' was intended to catch duplicate extensions, but it is bypassed when both counts are zero because v3d_get_multisync_post_deps() returns immediately for zero-count entries, leaving those fields unset on every pass. A pointer crafted as ext->next == &ext creates a cycle that the loop never escapes. The fix rejects any multisync extension with both counts at zero at the v3d_get_multisync_submit_deps() entry point. Affected CPE: cpe:2.3:a:linux:linux:*:*:*:*:*:*:*:* from the introduction commit e4165ae8304e5ea822fbe5909dd3be5445c058b7 through the stable-branch patch commits.
RemediationAI
Upgrade to Linux kernel 6.18.33, 7.0.9, or any 7.1-rc1+ build containing the fix, available via the kernel.org stable tree. The authoritative patches are at https://git.kernel.org/stable/c/4fa42a249e8cd6ed17aea04e5695b6e9001f2433, https://git.kernel.org/stable/c/9c5164781cb388d219d8f49fa0f0b04cf86ad544, and https://git.kernel.org/stable/c/fb44d589bf3148e13452185a6e772a7efbf2d684; distributions should apply whichever corresponds to their maintained kernel branch. If patching is not immediately possible, the primary compensating control is to restrict access to the /dev/dri/renderD* device node associated with the V3D GPU - removing world-read/write permissions or placing it behind a device access group will prevent unprivileged local users from submitting crafted ioctl extensions. Trade-off: this will break GPU-accelerated rendering for all non-root users. Alternatively, blacklisting the v3d kernel module (echo 'blacklist v3d' >> /etc/modprobe.d/v3d-disable.conf) eliminates the attack surface entirely at the cost of disabling VideoCore VI GPU acceleration. Neither workaround is necessary in single-user or trusted-user environments.
Same technique Denial Of Service
View allShare
External POC / Exploit Code
Leaving vuln.today