CVE-2026-74638: Linux Kernel DRM Scheduler Privilege Escalation

CVE-2026-74638 Overview

CVE-2026-74638 is a race condition in the Linux kernel's Broadcom V3D Direct Rendering Manager (DRM) driver. The V3D GPU exposes multiple independent hardware queues (BIN, RENDER, TFU, and CSD) but shares a single global reset. When a timeout occurs on one queue, concurrent timeout handlers on other queues can corrupt the scheduler's credit accounting. The driver-side reset_lock cannot cover the scheduler's job-list manipulation outside the timedout_job callback. The result is a broken credit count, a GPU hang, and a UI freeze on affected systems such as the Raspberry Pi 5.

Critical Impact
Concurrent GPU scheduler timeout handlers race on a shared pending list, producing an unrecoverable credit-count corruption that hangs the GPU and freezes the user interface.

Affected Products

Linux kernel with the drm/v3d driver enabled
Broadcom V3D GPU platforms including Raspberry Pi 5
Kernel builds prior to the fix in commits 4da94744707b, 5884851a096d, and c22a45817b9c

Discovery Timeline

2026-08-22 - CVE-2026-74638 published to NVD
2026-08-25 - Last updated in NVD database

Technical Details for CVE-2026-74638

Vulnerability Analysis

The V3D GPU driver registers a DRM scheduler instance for each hardware queue. Because the hardware only supports a global reset, a timeout on any queue must stop, reset, and restart every scheduler. The driver's reset_lock only serializes the drm_sched_backend_ops.timedout_job callback and does not extend to the scheduler's own manipulation of the pending job list.

When a timeout fires on the CSD queue while a compute-list intensive workload runs on the CL queue, the global reset invokes drm_sched_stop() and drm_sched_start() on the CL scheduler. Those routines subtract and add credits for every job on the pending list. Meanwhile, the CL queue's own timeout handler concurrently removes and reinserts its job on that same list. The stop and start observe different job sets, leaving the CL queue with more in-flight credits than its configured limit and triggering the WARN at drivers/gpu/drm/scheduler/sched_main.c:102 in drm_sched_run_job_work.

Root Cause

The root cause is missing serialization between per-queue timeout handlers that share a global hardware reset. Each scheduler queued its timeout work on the default system workqueue, which runs handlers concurrently. The DRM scheduler subsystem provides a mechanism for this exact scenario through the timeout_wq parameter of drm_sched_init(), which V3D did not use.

Attack Vector

This is a local reliability and denial-of-service condition triggered by GPU workload patterns rather than a remotely reachable code execution flaw. A user-space application submitting concurrent CSD compute and CL rendering jobs that provoke timeouts can induce the race. The result is a GPU hang and UI freeze on the affected system. No authentication bypass or memory corruption primitive has been reported.

See the upstream fix for technical details: Kernel Git Commit Fixes.

Detection Methods for CVE-2026-74638

Indicators of Compromise

Kernel WARNING at drivers/gpu/drm/scheduler/sched_main.c:102 in drm_sched_run_job_work originating from workqueues such as v3d_bin.
GPU hangs, display freezes, or unresponsive compositor sessions on V3D-based hardware after mixed CSD and CL workloads.
dmesg traces containing drm_sched_run_job_work+0x238/0x4d0 [gpu_sched] followed by scheduler credit warnings.

Detection Strategies

Monitor kernel logs for scheduler WARN_ON events emitted from the gpu_sched module on V3D platforms.
Correlate GPU workqueue names (v3d_bin, v3d_render, v3d_csd, v3d_tfu) with timeout-related stack frames to identify the race pattern.
Track kernel package versions across Linux fleets to identify hosts running V3D drivers built before the fix commits.

Monitoring Recommendations

Forward dmesg and journald GPU subsystem logs to a centralized logging tier for anomaly detection.
Alert on repeated GPU reset events on embedded and single-board-computer fleets that use Broadcom V3D silicon.
Track user-reported UI freeze incidents against kernel build metadata to prioritize patching.

How to Mitigate CVE-2026-74638

Immediate Actions Required

Apply the stable kernel updates containing commits 4da94744707b, 5884851a096d, and c22a45817b9c to serialize V3D scheduler timeout handlers on a shared ordered workqueue.
Rebuild and redeploy custom kernels used on Raspberry Pi 5 and other V3D-based platforms with the patched drm/v3d driver.
Reboot affected systems after patching to load the corrected scheduler initialization path.

Patch Information

The upstream fix creates a shared ordered workqueue and passes it as the timeout_wq argument to drm_sched_init() for all V3D queues. This serializes timeout handlers across BIN, RENDER, TFU, and CSD, matching the DRM scheduler documentation for hardware with distinct queues and a global reset. Patched commits are available at Kernel Git Commit Changes, Kernel Git Commit Fixes, and Kernel Git Commit Updates.

Workarounds

Avoid running concurrent compute (CSD) and complex CL rendering workloads on unpatched V3D systems where timeouts are observed.
Reduce GPU job complexity or increase job submission granularity to lower the probability of scheduler timeouts on affected kernels.
Where feasible, pin production workloads on Broadcom V3D hardware to kernel builds that already include the fix.

bash

# Verify the running kernel includes the V3D scheduler serialization fix
uname -r
grep -R "timeout_wq" /lib/modules/$(uname -r)/build/drivers/gpu/drm/v3d/ 2>/dev/null
dmesg | grep -E "v3d|drm_sched_run_job_work"