CVE-2026-46314: Linux Kernel V3D Driver DoS Vulnerability

CVE-2026-46314 Overview

CVE-2026-46314 is a denial-of-service vulnerability in the Linux kernel's Broadcom VideoCore V3D Direct Rendering Manager (drm/v3d) driver. The flaw exists in v3d_get_extensions(), which walks a userspace-provided singly-linked list of ioctl extensions without bounding the chain length. A local user can craft a self-referential extension where ext->next == &ext with zero in_sync_count and out_sync_count. This bypasses the existing duplicate-extension guard and produces an infinite loop in kernel context. The result is a pegged CPU core and a blocked calling thread.

Critical Impact

Local unprivileged users with access to the V3D DRM device can trigger an unbounded kernel-mode loop, exhausting a CPU core and causing local denial of service.

Affected Products

• Linux kernel versions containing the drm/v3d driver prior to the referenced stable commits
• Systems using Broadcom VideoCore V3D GPU hardware (notably Raspberry Pi platforms)
• Distributions shipping vulnerable stable kernel branches awaiting the upstream backport

Discovery Timeline

• 2026-06-08 - CVE-2026-46314 published to NVD
• 2026-06-08 - Last updated in NVD database

Technical Details for CVE-2026-46314

Vulnerability Analysis

The vulnerability resides in the V3D DRM driver's extension parsing logic. The function v3d_get_extensions() iterates through a linked list of drm_v3d_extension structures supplied directly by userspace through an ioctl call. The loop follows the next pointer on each iteration without tracking visited nodes or enforcing a maximum chain length.

A duplicate-extension guard exists inside v3d_get_multisync_submit_deps() that returns -EINVAL when se->in_sync_count or se->out_sync_count is non-zero on a repeated multisync extension. However, this guard never triggers when both counters are zero. The helper v3d_get_multisync_post_deps() returns immediately when count is zero, leaving the sync-count state untouched across iterations.

An attacker constructs a single extension node whose next pointer points back to itself with both sync counts set to zero. The kernel then walks this self-referential list forever, holding the calling thread in kernel mode and consuming 100% of one CPU core. This represents an infinite loop denial-of-service condition.

Root Cause

The root cause is incomplete input validation on userspace-controlled list structures combined with a guard condition that depends on state mutations that never occur in the zero-count path. The kernel trusts the userspace-supplied chain to terminate without enforcing an iteration bound.

Attack Vector

Exploitation requires local access and the ability to open the V3D DRM device node (typically /dev/dri/card* or /dev/dri/renderD*). The attacker invokes a V3D submit ioctl with a crafted extension chain containing a self-referential pointer and zeroed sync counts. No elevated privileges are required beyond standard DRM render node access, which is commonly granted to unprivileged users on desktop and embedded Linux systems.

The upstream fix in v3d_get_multisync_submit_deps() rejects any multisync extension where both in_sync_count and out_sync_count are zero, returning -EINVAL. An empty multisync carries no synchronization information, making this rejection a safe and complete defense against the attack pattern. Patches are tracked in commits 4fa42a249e8c, 9c5164781cb3, and fb44d589bf31 in the stable kernel tree.

Detection Methods for CVE-2026-46314

Indicators of Compromise

• A single thread sustained at 100% CPU utilization inside kernel mode (%sys time) with no corresponding userspace progress
• Soft lockup or RCU stall warnings in dmesg referencing the v3d driver call path
• Processes holding open file descriptors to /dev/dri/renderD* while exhibiting runaway kernel CPU consumption

Detection Strategies

• Monitor per-thread kernel CPU time and flag threads exceeding sustained thresholds while blocked in driver ioctls
• Audit kernel ring buffer output for watchdog: BUG: soft lockup messages referencing v3d_get_extensions or v3d_submit symbols
• Track ioctl invocation patterns against DRM render nodes from unprivileged processes using auditd or eBPF tracing

Monitoring Recommendations

• Enable kernel soft lockup detection (kernel.softlockup_panic or kernel.watchdog) to surface infinite-loop conditions early
• Collect process-level CPU and syscall telemetry from Linux endpoints to identify anomalous local processes triggering kernel stalls
• Correlate DRM device access with user account context to identify unexpected use of GPU ioctls by non-graphical workloads

How to Mitigate CVE-2026-46314

Immediate Actions Required

• Apply the upstream stable kernel patches referenced in commits 4fa42a249e8c, 9c5164781cb3, and fb44d589bf31 once available in your distribution
• Inventory systems using Broadcom V3D hardware and prioritize patching of multi-tenant or shared-access devices
• Restrict access to /dev/dri/renderD* device nodes to trusted users and groups where graphical workloads do not require broad availability

Patch Information

The fix modifies v3d_get_multisync_submit_deps() to reject multisync extensions where both in_sync_count and out_sync_count equal zero. Refer to the Kernel Git Commit 4fa42a249e8c, Kernel Git Commit 9c5164781cb3, and Kernel Git Commit fb44d589bf31 for the authoritative patch content.

Workarounds

• Remove or tighten permissions on V3D DRM device nodes for systems that do not require local GPU access
• Unload the v3d kernel module on systems where V3D hardware acceleration is not in use
• Apply kernel watchdog tuning to convert soft lockups into recoverable panics in environments where availability monitoring takes priority over uptime

# Restrict DRM render node access to the 'video' group only
sudo chgrp video /dev/dri/renderD128
sudo chmod 660 /dev/dri/renderD128

# Unload v3d driver where unused (verify no active GPU consumers first)
sudo modprobe -r v3d

# Enable soft lockup panic to fail fast on infinite kernel loops
sudo sysctl -w kernel.softlockup_panic=1