# VERDICT — DF-4729

* **status: untested** (permitted enum; contract category would be "skipped/not_testable")
* **reproduced: 0** · **impact: none (demonstrated)** — *would be `panic` on target hardware*
* **confidence: certain** (defect logic), reachability root/config-gated

## Narrative

Pass-2 audit of `sys/dev/drm/i915/intel_guc.c` (known: DF-1826 shared_data_vaddr
dangling — not re-reported; verified not to have a *second* distinct lifetime
consumer: `shared_data_vaddr` is read only at intel_guc_submission.c:635, which
is DF-1826's manifestation).

New finding: a **dead-code divergence panic**. This port compiled out the GuC
log subsystem's construction (`#if 0` at intel_guc.c:71-73 and :202-206 —
`intel_guc_log_init_early` and `intel_guc_log_create`) but kept its
*consumption*: `guc_ctl_log_params_flags()` dereferences `guc->log.vma`
(intel_guc.c:296). `log->vma` is assigned in exactly one place in the tree —
`intel_guc_log_create()` at intel_guc_log.c:489 — which has zero live call
sites. `guc->log.vma` is therefore NULL for the driver's lifetime.

Call chain (all verified live):

```
i915_gem.c:5746  i915_gem_init_hw()            [driver load / resume]
 └─ intel_uc.c:377   intel_uc_init_hw() — no fw-fetch-status guard before the call
     └─ intel_guc.c:359 intel_guc_init_params()
         └─ intel_guc.c:296 guc_ctl_log_params_flags()
             └─ intel_guc.h:137-143 intel_guc_ggtt_offset(guc, NULL)
                 └─ i915_vma.h:202-208 i915_ggtt_offset(NULL)
                     ├ debug GEM build: GEM_BUG_ON(!i915_vma_is_ggtt(NULL)) → vma->flags read → page-0 fault
                     └ release build: lower_32_bits(vma->node.start) → NULL+offset read → page-0 fault
```

Either build panics. The panic fires *before* firmware upload is attempted,
so even a missing firmware file does not avoid it.

## Why untested (not false_positive)

The defect is statically certain (run `./verify.sh`, output in
`static_proof.log`). It is **not false_positive**: the cited path is live
whenever `USES_GUC()` is true. It is not verified at runtime because the
audit guest has no Intel Gen9+ display device (QEMU vgapci chip=0x11111234,
see env.txt) — i915 cannot attach, and no emulation knob exists to inject
one. The trigger precondition (`i915.enable_guc=1/-1`, default **0** at
i915_params.h:49, root-only to set) additionally gates it behind an admin
action, which is why this is filed Low rather than High.

## Exploit chain

None — configuration-gated denial of service (kernel panic at GPU init) on
hardware an attacker cannot summon. No path to uid=0.

## Negative results (classes hunted and killed in this file)

* `intel_guc_init` error unwind double-`intel_uc_fw_fini`: **killed** —
  `intel_uc_fw_fini` is `fetch_and_zero`-based (intel_uc_fw.c:278-287),
  idempotent.
* `guc_shared_data_create` pin_map-failure unwind leaking the pin: released
  via `i915_vma_unpin_and_release(&vma, 0)` (intel_guc.c:177) — the helper
  unconditionally unpins; no leak.
* `intel_guc_init_params` SOFT_SCRATCH overflow: **killed** —
  `GUC_CTL_MAX_DWORDS = SOFT_SCRATCH_COUNT - 2` (intel_guc_fwif.h:132),
  writes SOFT_SCRATCH(1..14) ⊂ SOFT_SCRATCH(0..15).
* `intel_guc_send_mmio` len/response bounds: GEM_BUG_ON-asserted only in
  debug builds, but `len`/`response_buf_size` come solely from in-kernel
  constant action arrays (this file :504/:530/:544/:561, submission, huc) —
  not attacker-influenced; `count = min(response_buf_size, send_regs.count-1)`
  bounds the copyout.
* `guc->send`/`guc->handler` pointer swap vs in-flight send race (suspend vs
  execbuf): upstream design; requires GuC submission (disabled by default,
  `enable_guc=0`); no memory-safety consequence demonstrated — noted, not
  filed.
* IRQ path `intel_guc_to_host_event_handler_mmio` (intel_guc.c:462-487):
  irq_lock-protected read-modify-write of SOFT_SCRATCH(15), mask-bounded —
  clean.

## Fix validation

Not possible on this guest (no target hardware): `fix_status: not_testable`.
`fix.diff` guards the flags computation on `guc->log.vma != NULL`, returning
0 (GuC logging disabled — consistent with the port's removal of the log
subsystem).

## 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.