Executive brief
The Linux kernel's DRM v3d driver manages graphics processing on Raspberry Pi 5 and similar devices. A concurrency bug in timeout handling across independent hardware queues can cause the GPU scheduler's credit tracking to become corrupted, resulting in complete GPU hangs and system UI freezes when timeouts occur simultaneously on different queues during intensive graphics workloads.
Technical details
The vulnerability is a race condition in the v3d driver's timeout handler serialization. V3D hardware exposes multiple independent queues (BIN, RENDER, TFU, CSD) but shares a single global reset mechanism. When a timeout occurs on one queue, the driver must reset all queues globally. However, the driver's reset_lock only protects the timedout_job callback; the scheduler's pending list manipulation (drm_sched_stop/start) occurs outside driver control. If a global reset is triggered while another queue's handler is concurrently processing its timeout, drm_sched_stop() and drm_sched_start() see inconsistent job lists, leaving the scheduler with incorrect job credit counts. This manifests as kernel warnings in drm_sched_run_job_work() and causes complete GPU hangs. The fix is to use the DRM scheduler's ordered workqueue mechanism (timeout_wq parameter) to serialize timeout handlers across all queues, as recommended by scheduler documentation for globally-resetting hardware.
Affected products
- Linux Linux kernel 6.18.39 and likely earlier versions
Timeline
- 2026-08-22: disclosed: Published in NVD
- 2026-08-22: patched: Resolved upstream in Linux kernel with serialized timeout handler mechanism