CVE-2026-46314

What it actually does

This is a local denial-of-service flaw in the Linux kernel V3D DRM graphics driver. The vulnerable code walks a userspace-supplied linked list of ioctl extensions without a safe bound or rejection of an empty multisync extension. A local process with access to the V3D DRM device can submit a self-referential extension whose next pointer points back to itself and whose input/output sync counts are both zero. Because the duplicate-extension guard is bypassed, the kernel remains in an infinite loop in kernel context, tying up the calling thread and consuming a CPU core indefinitely.

Why it matters to the business

Systems using the affected Linux kernel V3D graphics driver can suffer local resource exhaustion, degraded performance, or service instability if an untrusted local user or compromised process can access the DRM device. The most likely impact is availability loss on devices using V3D graphics, such as embedded, workstation, kiosk, or Raspberry Pi-class systems. This issue is not known to be exploited in the wild, is not listed in CISA KEV, has very low EPSS, and has no reported ransomware use, so urgency is highest for multi-user systems or systems that expose GPU/DRM access to containers, sandboxes, or untrusted workloads.

How an attack unfolds

An attacker first needs local code execution on a system with the vulnerable V3D DRM driver available and sufficient permission to open the relevant DRM device node, commonly under /dev/dri. The attacker then issues a crafted V3D ioctl containing an extension chain where a multisync extension is empty, with both in_sync_count and out_sync_count set to zero, and the extension next pointer refers back to the same structure. The kernel begins walking the extension list, repeatedly processes the same empty multisync extension, and never reaches a terminating condition. The attacking process becomes stuck in kernel context while a CPU core remains pegged, reducing system capacity and potentially causing operational disruption if repeated or combined with other resource-exhaustion activity.

How to fix it

Apply a Linux kernel update that includes the V3D DRM fix rejecting empty multisync extensions where both in_sync_count and out_sync_count are zero. If distribution-specific fixed package versions are not available, track the fix through the kernel vendor or distribution advisory for the affected kernel stream. As mitigations, restrict access to V3D DRM device nodes to trusted users only, review udev/logind permissions for /dev/dri devices, avoid passing DRM devices into untrusted containers, disable or unload the V3D driver where it is not required, and use cgroup CPU controls to limit the blast radius of untrusted local workloads. Reboot into the patched kernel after updating; replacing kernel packages alone is not sufficient until the running kernel is updated.

How to confirm the fix worked

Confirm the running kernel contains the V3D DRM fix, not just that an updated package is installed. Validate by checking the active kernel version against the distribution advisory or upstream stable release containing the patch. On source-based or custom kernels, verify the V3D driver rejects empty multisync extensions in v3d_get_multisync_submit_deps(). Confirm whether the system exposes V3D DRM device nodes under /dev/dri and whether untrusted users, containers, or services can open them. After patching and rebooting, a regression or proof-of-concept test should receive an error such as EINVAL rather than causing a stuck ioctl and sustained CPU consumption.

Typical attack path

1. Gain local execution as a user or process on a system running an affected Linux kernel with the V3D DRM driver enabled.
2. Confirm access to a V3D DRM device node such as a render or card device under /dev/dri.
3. Open the DRM device from userspace and prepare a V3D ioctl request using the multisync extension mechanism.
4. Construct an empty multisync extension where both synchronization counts are zero.
5. Set the extension next pointer to reference the same extension, creating a self-referential linked list.
6. Submit the ioctl to the kernel driver.
7. Cause the kernel to loop indefinitely while processing the extension chain, consuming CPU and degrading availability.

How to detect it

Detection should focus on evidence of local resource exhaustion involving the V3D DRM driver. Review kernel logs, system journals, audit logs, endpoint telemetry, and performance data for processes that opened /dev/dri devices and then remained stuck in ioctl system calls while consuming sustained CPU. Look for hung-task messages, soft lockup reports, kernel stack traces, or perf samples containing V3D functions such as v3d_get_extensions or multisync handling paths. Auditd or eBPF telemetry can help identify processes opening /dev/dri/renderD* or /dev/dri/card* immediately before CPU saturation. Container platforms should be checked for workloads with DRM device passthrough. There may be no durable file artifact because exploitation can be performed entirely through an ioctl from memory; absence of logs does not rule out exploitation.

• /dev/dri/renderD
• /dev/dri/card
• v3d_get_extensions
• v3d_get_multisync_submit_deps
• v3d_get_multisync_post_deps
• v3d_submit_cl_ioctl
• drm/v3d
• v3d
• soft lockup
• hung_task
• blocked for more than
• INFO: task
• ioctl

What your security team should do

• Inventory Linux systems with V3D DRM enabled, especially embedded, kiosk, lab, desktop, and Raspberry Pi-class devices.
• Prioritize patching multi-user systems and systems where containers, sandboxes, CI jobs, or untrusted applications can access /dev/dri devices.
• Update to a kernel build that includes the V3D empty multisync rejection fix and reboot into the patched kernel.
• Temporarily restrict permissions on /dev/dri devices or remove DRM device passthrough from untrusted containers until patched.
• Monitor for unexplained sustained single-core CPU saturation by processes stuck in DRM/V3D ioctl paths.
• Review kernel logs, hung-task reports, crash dumps, and performance profiles for V3D driver stack frames.
• Because this is not currently KEV-listed and has very low EPSS, handle as a targeted local availability risk rather than an internet-scale emergency.