# DF-4736 VERDICT — INCONCLUSIVE (feature absent on guest; path statically dead on every platform today)

**Status:** inconclusive / impact: none / confidence: certain
(that the asymmetry exists AND that it is unreachable in this tree).

## What was investigated

Pass-2 audit of sys/dev/drm/i915/intel_hotplug.c. The candidate:
intel_hotplug.c:486-487 performs

```c
	if (storm_detected && dev_priv->display_irqs_enabled)
		dev_priv->display.hpd_irq_setup(dev_priv);
```

while both sibling call sites guard the same pointer:

* :244  `if (dev_priv->display_irqs_enabled && dev_priv->display.hpd_irq_setup)`
* :532  `if (dev_priv->display_irqs_enabled && dev_priv->display.hpd_irq_setup)`

If `hpd_irq_setup` were NULL while a storm is detected on an HPD-enabled pin,
this is an indirect call through NULL → immediate kernel panic.

## Why it cannot fire in this tree (line-by-line)

1. `display.hpd_irq_setup` is assigned only in `intel_irq_init()`
   (i915_irq.c:4853–4916). Every branch assigns it **except** the GMCH
   branch, which assigns it only `if (I915_HAS_HOTPLUG(dev_priv))`
   (i915_irq.c:4915-4916).
2. `I915_HAS_HOTPLUG` is `info.has_hotplug` (i915_drv.h:2634). The only
   platform entries without it are gen2 and i915G/i915GM
   (i915_pci.c:130–141 — `intel_i915gm_info` has no `has_hotplug`; the first
   `has_hotplug = 1` entries are i945g/i945gm at i915_pci.c:143-158).
3. On GMCH, `intel_hpd_irq_handler()` is reached only via
   `i9xx_hpd_irq_handler()`, which is called only when `hotplug_status != 0`
   (i915_irq.c:4600-4601, 4633-4634 pattern), and the ack that produces
   `hotplug_status` is gated:
   `if (I915_HAS_HOTPLUG(dev_priv) && iir & I915_DISPLAY_PORT_INTERRUPT)`
   (i915_irq.c:4584-4586 in `i915_irq_handler`; same gate in
   `i965_irq_handler` for gen4+, and gen2 `i8xx_irq_handler` has no hotplug
   path at all). On !has_hotplug platforms `hotplug_status` stays 0 →
   `intel_hpd_irq_handler()` never runs → :486 is dead code there.
4. On every platform where `intel_hpd_irq_handler()` CAN run,
   `hpd_irq_setup` was assigned in step 1.

Net: today the missing guard is unreachable; it is a latent NULL-call hazard
for future platform additions. Severity Info, no runtime impact demonstrable.

## Guest verification (environmental dead-end, live-checked)

Guest `pciconf -l` (env.txt): the only Intel devices are 440FX host bridge
(8086:1237), PIIX3 ISA (8086:7000), PIIX3 ATA (8086:7010), PIIX4 PM
(8086:7113). **No Intel VGA/display controller** → i915 never attaches on
this QEMU guest → HPD interrupts, storm detection, and the entire file are
runtime-unreachable here. A kernel-build PoC cannot exercise an IRQ-path NULL
call without the hardware; a KLD stub that calls the function pointer with a
NULL setup would only restate the tautology (calling NULL panics).

## Attempts

1. Static reachability trace (i915_irq.c + i915_pci.c + intel_hotplug.c) —
   killed exploitability for the current platform table (certain).
2. Live guest environment check — no Intel GPU (env.txt).

## Fix

`fix.diff` adds the guard, making :486 identical in shape to :244/:532.
Not built/booted: an Info-latent finding with no observable behavior change
on any existing platform (the guard is a no-op for every reachable
configuration), and the guest has no i915 hardware — a patched-kernel
comparison has nothing to compare. fix_status = not_testable for that
reason.

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