# DF-5581 VERDICT — not_reproduced on rig (hardware absent); root cause code-certain

**Status:** `not_reproduced` on the available QEMU rig — the triggering
hardware (Intel gen3+ integrated GPU at PCI 0:2:0) does not exist in QEMU and
cannot be emulated without patching QEMU itself. The root cause is proven
with line-accurate code reading plus live guest probes of the observable
surface.

## The finding (code-certain)

`intel_graphics_stolen()` runs at `init386()` time
(`sys/platform/pc64/x86_64/machdep.c:2760`, before `cninit()`), reads the
firmware-programmed BSM (`0x5c` / gen11 `0xc0/0xc4`) and GMCH (`0x50/0x52`)
registers of the Intel iGPU at 0:2:0, and stores base/size into
`intel_graphics_stolen_base/size` (`pci_early_quirks.c:303-304`).

The function's own comment (`:264-271`) states its purpose: buggy BIOSes do
not reserve the GPU's stolen memory, so the OS can claim it before the GPU
driver loads; the function is supposed to **reserve** it. It does not:

* The only reservation call is commented out (`pci_early_quirks.c:308-310`).
* `phys_avail_reserve` does not exist anywhere in the tree — live-proven on
  the guest over the full `/usr/src`: exactly one hit, the comment itself
  (`run.log`). The `x86/physmem.h` include is commented out too (`:35-36`).

## The consumer side (why "inert globals" are not the end of the story)

1. `sys/dev/drm/i915/i915_module.c:18-30` (`i915_init`, SI_SUB_DRIVERS):
   `intel_graphics_stolen_res = DEFINE_RES_MEM(intel_graphics_stolen_base,
   intel_graphics_stolen_size)` and prints both values.
2. `sys/dev/drm/i915/i915_gem_stolen.c:414-417` (`i915_gem_init_stolen`):
   non-zero size ⇒ `dev_priv->dsm = intel_graphics_stolen_res` — the driver
   adopts the range as GPU-exclusive and allocates GPU objects (ringbuffers,
   contexts, framebuffers…) from it via `drm_mm`.
3. The only overlap check on the whole path is
   `devm_request_mem_region()` at `i915_gem_stolen.c:177-189` — whose
   DragonFly implementation (`i915_gem_stolen.c:85-102`) builds a **static
   rman scoped to exactly `[start, start+n)`** (the region being requested),
   `rman_manage_region`s that same range, and returns success. It cannot see
   any other resource; the "conflict detected" branch is unreachable in
   practice. Upstream Linux semantics (fail if any kernel/driver resource
   occupies the range) are not present.

## Impact chain (conditional, stated exactly)

Preconditions: Intel gen3+ iGPU at 0:2:0 (the table
`pci_early_quirks.c:227-262` covers ~200 Intel device IDs), i915 drm module
in use, AND firmware that fails to hide the stolen range from the OS memory
map (the exact bug class this quirk exists for — real-world occurrences are
documented in the Linux early-quirks history this code was ported from), or
BSM/GMS register values inconsistent with the memory map.

Consequence: the kernel physical page allocator and the i915 stolen
allocator own the same DRAM pages. The GPU then DMAs over live kernel
data structures → silent kernel memory corruption (integrity/confidentiality
of kernel memory from the GPU's perspective, availability certain). No
unprivileged-local software trigger exists: the inputs are
firmware-programmed config registers; local unprivileged users cannot reach
them (config access requires root via /dev/pci, which is FWRITE-gated).

Severity: Medium (kernel memory corruption consequence, but requires the
specific hardware + misbehaving firmware precondition; not attacker-actioned
from an unprivileged shell). Confidence: certain for the code gap; the
population of affected machines is the uncertainty.

## What was run on the guest (run.log)

* `sysctl hw.intel_graphics_stolen_base hw.intel_graphics_stolen_size` as
  `uid=1001` → both readable (world-readable sysctl surface), value `0`.
* `pciconf -l` → `vgapci0@pci0:0:2:0: class=0x030000 chip=0x11111234` —
  passes the class gate (`pci_early_quirks.c:291-292`), fails the vendor
  gate (`:287-289`, vendor 0x1234 ≠ 0x8086) → quirk correctly inert on this
  rig; i915 not loaded.
* Full `/usr/src` grep for `phys_avail_reserve` → only the comment at
  `pci_early_quirks.c:309`.

Attempts: 3 distinct guest probes (sysctl / pciconf / tree grep), all
consistent with the code analysis.

## Why no escalation chain was pursued

The corruption primitive is GPU-DMA-based and requires an Intel iGPU device
model at 0:2:0. QEMU ships none (VGA = 1234:1111, vmware-svga = 15ad:0405,
virtio-gpu = 1af4:1050); making 0:2:0 read `8086:<id>` requires patching
QEMU device models (out of scope for this rig). There is no
unprivileged-local software path into the inputs. "No gadget / hardening
blocks me" does NOT apply here — the blocker is hardware availability, and
it is total on this rig.

## Fix

`fix.diff`: stop advertising the unreserved range to drm/i915 (zero-size the
resource in `i915_init`), which activates the driver's own documented safe
fallback (`i915_gem_stolen.c:414-415`: zero size ⇒ stolen memory disabled —
the same fallback Linux uses under DMAR/vGPU). Kernel-side diagnostic sysctls
keep the raw firmware values. The complete fix (implement the
`phys_avail_reserve` KPI at init386 and re-enable advertising) is the
follow-up maintainer work; the diff removes the unsafe trust now.

Fix validation: `fix_status=not_testable` — the baseline harmful behavior
cannot be reproduced on this rig (no Intel GPU), so a baseline→patched
comparison is impossible here. The patched consumer path was verified by
code: `DEFINE_RES_MEM(0,0)` ⇒ `end=-1` ⇒ `resource_size()==0`
(`sys/dev/drm/include/linux/pci.h:621-637`) ⇒ early `return 0`.

## Negative sweep (classes considered and killed)

* Table matching (`:299-306`): bounded by `nitems()`, all entries fully
  initialized by `INTEL_VGA_DEVICE` (vendor 0x8086, device, ops); per-entry
  `.vendor` is ignored but pre-validated once at `:288` — equivalent, safe.
* Early cfgreg access: every read uses fixed (bus,slot,func) ∈ {(0,2,0),
  (0,0,0)} and reg ∈ {0x00,0x02,0x0a,0x50,0x52,0x5c,0xc0,0xc4} with bytes
  ∈ {2,4} aligned — all pass `pci_cfgenable` bounds
  (`pci_cfgreg.c:181-196`); the ECAM width/alignment asymmetry is DF-5570
  (sibling file), not reachable from this file's call sites.
* Integer overflow: sizes are `vm_paddr_t` (64-bit) × max 0xEF·32MiB ≈
  7.5GiB — no overflow; `MiB()` shifts in `unsigned long`.
* Uninitialized reads / type confusion: `ops` only dereferenced after table
  match; table fully const-initialized; no writes to config space anywhere
  in this file.
* Races: single-threaded BSP boot before SMP start; globals written once,
  consumed at SI_SUB_DRIVERS — no race window.
* Info leak: `hw.intel_graphics_stolen_base/_size` are world-readable
  sysctls exposing a firmware-programmed physical address — noted as an
  Info-grade hardening nit (not filed; value is not a kernel pointer, no
  demonstrated impact; also inert at 0 on rigs without Intel GPU).

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