DF-4314 — intel_overlay: GPU-reset vs overlay-off lifetime race → NULL-crtc write / GEM_BUG_ON panic

What

intel_overlay_reset() (invoked from i915_reset()) tears down overlay state (overlay->crtc = NULL, releases old_vma) without regard for a concurrent, still-in-flight intel_overlay_off() — whose retire callback intel_overlay_off_tail() then executes overlay->crtc->overlay = NULL with overlay->crtc == NULL (NULL+offset kernel write → page fault → panic), or whose pending last_flip makes the reset's own intel_overlay_release_old_vid() slowpath trip GEM_BUG_ON() in intel_overlay_submit_request() → BUG() → panic.

• File: sys/dev/drm/i915/intel_overlay.c
• Lines: 220-221 (GEM_BUG_ON), 364-379 (intel_overlay_off_tail, crash at 373), 435-475 (intel_overlay_release_old_vid), 477-490 (intel_overlay_reset)
• Reset entry: i915_drv.c:2356 (intel_overlay_reset inside i915_reset), executed from inside a sleeping overlay waiter's own wait loop (i915_request.c:1250-1260 __i915_wait_request_check_and_reset, i915_gem_active_retire uses I915_WAIT_LOCKED, i915_request.h:701-722).

Build / Run (exact)

Guest (audit QEMU, no i915 hardware — honest device-absent run):

vm.sh run_root 'cc -O2 -I/usr/src/sys/dev/drm/include -o /tmp/trigger /tmp/trigger.c'
vm.sh run_root '/tmp/trigger /dev/dri/card0'

On real hardware (Gen2–Gen5 Intel GPU with overlay unit):

cc -O2 -I/usr/src/sys/dev/drm/include -o trigger trigger.c
./trigger /dev/dri/card0 &            # DRM-master overlay on/off hammer
# in parallel, as an UNPRIVILEGED user: induce GPU hangs (e.g. endless
# oversized GEM batchbuffers) so i915_reset() fires while an overlay-off
# request is pending; watch for panic in intel_overlay_off_tail / GEM_BUG_ON.

Expected

• Vulnerable HW: kernel panic — either Fatal trap 12: page fault writing 0+offsetof(struct intel_crtc, overlay) from intel_overlay_off_tail, or GEM_BUG_ON(i915_gem_active_peek(...)) → BUG() from intel_overlay_submit_request.
• Audit guest (this run): trigger compiles clean; open("/dev/dri/card0") → ENOENT; exit 2. The i915 driver cannot attach (Bochs/virtio VGA only — env.txt), so the path is unreachable at runtime on this guest.

Artifacts

• trigger.c — DRM-master race half (overlay on/off hammer)
• build.log, run.log, env.txt — full guest compile/run output + PCI/env
• fix.diff — verified git apply --check-clean two-hunk fix
• VERDICT.md — full narrative and code-path proof
• manifest.json, verdict.json

DF-4314 VERDICT — not_reproduced on the audit guest (device absent); race proven structurally in source

Reproduced?

No — on this guest it is impossible by construction. The audit QEMU guest has no Intel GPU: pciconf -l shows only vgapci0 chip=0x11111234 (Bochs/VBE virtio VGA), /dev/dri and /dev/drm do not exist (run.log, env.txt), and no drm/i915 module is loaded. HAS_OVERLAY() is never true, intel_setup_overlay() never runs, and the ioctl entry points return -ENODEV — in fact the drm2 device never attaches at all. The trigger therefore fails at open() with ENOENT (exit 2). Per the audit status vocabulary this is a device/feature-absent environment; recorded as not_reproduced / reproduced=0 / impact=none for what was observable on this guest, with the code-level analysis below.

Why the bug is real (source-level proof)

The two colliding paths

Path A — overlay off (DRM master, e.g. X stopping Xv video):

1. intel_overlay_put_image_ioctl with !I915_OVERLAY_ENABLE (intel_overlay.c:1075-1085), or a CRTC dpms disable (intel_display.c:5221-5229), calls intel_overlay_switch_off (intel_overlay.c:856).
2. intel_overlay_off (:382-421) calls intel_overlay_flip_prepare(overlay, NULL) (:417) — moves the live vma into overlay->old_vma — then submits the MI_OVERLAY_OFF request with retire callback intel_overlay_off_tail and sleeps in intel_overlay_do_wait_request → i915_gem_active_retire (:419-420, i915_request.h:701-722).

Path B — GPU reset:

3. The wait uses I915_WAIT_LOCKED; a waiter that observes reset handoff executes i915_reset() itself from inside its wait loop (i915_request.c:1320-1322 → __i915_wait_request_check_and_reset :1250-1260). Independently, any other WAIT_LOCKED waiter or the error handler can perform the reset.
4. i915_reset (i915_drv.c:2291, lockdep_assert_held(struct_mutex) holds the mutex Path A dropped around its sleep) calls i915_gem_reset() — completing Path A's still-in-flight off request — and then intel_overlay_reset(i915) (i915_drv.c:2356).
5. intel_overlay_reset (intel_overlay.c:477-490) runs intel_overlay_release_old_vid(overlay): - if the DOVSTA flip-pending bit is clear (:449), it frees old_vma via the direct tail call (:471-472) — last_flip is not detached, the pending off_tail retire remains registered; - if the bit is set, it takes the slowpath, which calls intel_overlay_submit_request (:216-226) whose GEM_BUG_ON(i915_gem_active_peek(&overlay->last_flip, …)) fires because last_flip still tracks the completed-but-unretired OFF request → BUG() → panic (GEM_BUG_ON is unconditionally fatal: i915_gem.h:42-49). Then it sets overlay->crtc = NULL; overlay->active = false (:488-489).

The crash

6. Path A's i915_gem_active_retire resumes: the request is now complete, so it detaches last_flip and invokes the retire callback — intel_overlay_off_tail (i915_request.h:719: active->retire(active, request); intel_overlay.c:364-379).
7. off_tail runs intel_overlay_release_old_vma (WARN_ON(!vma) — old_vma was already freed in step 5, WARN only, :340-353) and then executes

c overlay->crtc->overlay = NULL; /* intel_overlay.c:373 */

with overlay->crtc == NULL (cleared in step 5) → kernel write to 0 + offsetof(struct intel_crtc, overlay) (an absolute low address, unmapped) → page fault in kernel mode → panic.

There is no NULL guard anywhere on this path, and the alternative retire-worker ordering (Path A aborted earlier by a signal, the OFF request retired by the periodic i915_retire_requests worker after the reset) reaches the identical off_tail NULL dereference. Both interleavings are architecturally enabled by design: WAIT_LOCKED waits exist precisely so the waiter runs the reset inline.

Reachability / attacker model

• The overlay-off half is DRM-master territory (X stopping Xv, or a CRTC dpms disable — kernel-internal, intel_display.c:5228).
• The reset half is triggerable by an unprivileged local user: GPU hangs from unprivileged GL/GEM clients are the canonical i915 reset trigger, and i915_handle_error/hangcheck then schedules exactly the i915_reset → intel_overlay_reset path raced above. When the GPU hangs, the master's in-flight overlay-off wait blocks until the reset — i.e. the "overlay-off pending during reset" condition is the common case whenever video playback/modeset coincides with a hang, not a narrow window.
• Requires Gen2–Gen5 Intel graphics with the overlay unit (HAS_OVERLAY); Ironlake+ (no overlay) is unaffected.

Impact: local kernel panic (DoS) — no controlled data is written (fixed NULL base + fixed small offset), no info leak. Race-condition reliability: high on hang coincidence, but not 100% deterministic → severity Medium, CWE-362/CWE-476.

Fix validation

fix.diff (two hunks) — git apply --check clean against this tree:

1. intel_overlay_off_tail: NULL-guard overlay->crtc (kills crash shape 6-7).
2. intel_overlay_reset: retire the pending last_flip first, while overlay->crtc is still valid (kills both the deferred-NULL-deref and the GEM_BUG_ON shape — release_old_vid afterwards finds old_vma already released by the properly-ordered retire).

fix_status: not_testable — validating on this guest is impossible: the driver cannot attach (no Intel GPU), so neither baseline nor patched kernel can execute the path. The fix was instead validated by re-deriving every interleaving (reset-inside-wait, reset-inside-error-handler, deferred retire worker) against the patched source: each ordering now retires off_tail with crtc valid before any NULL assignment.

Artifacts

trigger.c (code_hash a6499d4a5144fd6e4c159a43f8c8db24cdc3a4afac57f53c36da096aed46c7b4), build.log (clean guest compile), run.log (device-absent result), env.txt (guest PCI/DRM inventory), fix.diff, manifest.json, verdict.json.

Fix status (batch validation)

Applied with the 36 sibling fix.diffs of this batch in findings/poc/_batch41/all_fixes.patch; single in-guest make -j6 nativekernel KERNCONF=X86_64_GENERIC completed RC=0 with zero errors under -Werror (full log: findings/poc/_batch41/fix_build8.log). Behavior A/B intentionally skipped for this Info-tier item.