DF-4729 — intel_guc: guc_ctl_log_params_flags() NULL-derefs guc->log.vma (log buffer is never created on this port)

File: sys/dev/drm/i915/intel_guc.c — pass 2 (GLM 5.3 re-audit) Severity: Low · CWE-476 · confidence: certain (defect), reachability gated on i915.enable_guc

What

intel_guc_init_params() (intel_guc.c:340-379) unconditionally computes params[GUC_CTL_LOG_PARAMS] = guc_ctl_log_params_flags(guc) (intel_guc.c:359), and guc_ctl_log_params_flags() (intel_guc.c:294-333) starts with:

u32 offset = intel_guc_ggtt_offset(guc, guc->log.vma) >> PAGE_SHIFT;   // :296

On this DragonFly port intel_guc_log_create() is compiled OUT — its only call site is inside #if 0 at intel_guc.c:202-206 (the same #if 0 also guts intel_guc_log_init_early, intel_guc.c:71-73). The only assignment to log->vma in the tree is inside intel_guc_log_create() (intel_guc_log.c:489), which is never called. drm_i915_private is zero-initialized, so guc->log.vma == NULL forever.

intel_guc_ggtt_offset(guc, NULL) → i915_ggtt_offset(NULL) (i915_vma.h:202-208):

GEM_BUG_ON(!i915_vma_is_ggtt(vma));   /* vma->flags — NULL deref in debug builds */
...
return lower_32_bits(vma->node.start); /* NULL+offset read in release builds */

Either way: page-0 fault → kernel panic, in the driver-load / GPU-resume path (intel_uc_init_hw() at intel_uc.c:377 → called from i915_gem_init_hw, i915_gem.c:5746).

Reachability (why Low, not higher)

• enable_guc defaults to 0 on this port (i915_params.h:49, param(int, enable_guc, 0)); USES_GUC() is false unless root sets i915.enable_guc=1/-1 (module param / loader tunable, sysctl mode 0400 — root-only). The auto-enable branch (sanitize_options_early, intel_uc.c:110-111) only fires for the auto value -1, which is not the default here.
• Requires Intel Gen9+ hardware with GuC (HAS_GUC).
• With GuC enabled, the panic is unconditional and immediate at intel_uc_init_hw — before firmware upload even matters: there is no fw-fetch-status check before intel_guc_init_params(guc) (intel_uc.c:377), so even a missing firmware blob does not save it.

Threat model: an admin who enables the (advertised, supported) GuC/HuC feature gets an instant kernel panic at load/resume. Not attacker-triggerable without root. Same dead-code-divergence family as the pass-2 intel_guc_ct hardening findings (DF-4567/4568): the port disabled a subsystem's setup but left its use compiled in.

Reproduce (static proof — runnable)

Run ./verify.sh in this directory (uses only rg/sed against the repo):

1. intel_guc_log_create has no live call site (only #if 0 at intel_guc.c:203).
2. log->vma is assigned nowhere else.
3. guc_ctl_log_params_flags dereferences it, and is called unconditionally from intel_guc_init_params ← intel_uc_init_hw:377 ← i915_gem.c:5746.
4. i915_ggtt_offset() derefs vma in both debug and release builds.
5. enable_guc default is 0 → gate.

Why not verified on the QEMU guest

The audit guest (DragonFly 6.5-DEVELOPMENT, QEMU vgapci chip=0x11111234) has no Intel Gen9+ display device; i915 never attaches, so the GuC path cannot be exercised. No hardware emulation knob is available to inject an Intel GPU. Status recorded as untested (permitted enum), impact would be panic on target hardware.

Recommended fix

Guard the flags computation on the log buffer actually existing (consistent with this port having disabled GuC logging):

--- a/sys/dev/drm/i915/intel_guc.c
+++ b/sys/dev/drm/i915/intel_guc.c
@@ -291,9 +291,15 @@ static u32 guc_ctl_debug_flags(struct intel_guc *guc)

 static u32 guc_ctl_log_params_flags(struct intel_guc *guc)
 {
-   u32 offset = intel_guc_ggtt_offset(guc, guc->log.vma) >> PAGE_SHIFT;
+   u32 offset;
    u32 flags;

+   /* The port does not create the log buffer (intel_guc_log_create
+    * is compiled out); do not hand the firmware a bogus log params
+    * dword — and do not dereference a NULL vma. */
+   if (!guc->log.vma)
+       return 0;
+
+   offset = intel_guc_ggtt_offset(guc, guc->log.vma) >> PAGE_SHIFT;
+
    #if (((CRASH_BUFFER_SIZE) % SZ_1M) == 0)

(Returning 0 leaves GUC_LOG_VALID unset → GuC logging disabled, which matches the port's intent. The alternative — re-enabling intel_guc_log_create() — requires the relay/debugfs infrastructure this port also removed.)

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.