# DF-4678 — VERDICT

**Status: UNTESTED on the guest (no Intel GPU; the shim cannot execute) ·
impact: none directly demonstrable / silent kernel-memory corruption on
affected firmware · confidence: certain (code facts) · fix: not_testable
(git-apply clean, hardware-gated)**

## Facts (all line-verified against the guest's /usr/src, md5-matched)

1. `i915_adjust_stolen()` (i915_gem_stolen.c:106-191) uses
   `devm_request_mem_region()` at :162 as its only "is this physical range
   really free" gate, with the comment *"if the region is already marked as
   busy, something is seriously wrong"* and the `-EBUSY` bail at :182-187
   (GEN3 excepted).
2. On DragonFly that call resolves to the local shim at :83-104: it creates a
   **private static `struct rman`**, `rman_init` + `rman_manage_region`, and
   returns a kmalloc'd token. It cannot observe any other driver's
   reservations, and `rman_manage_region()` itself does no overlap checking
   (sys/kern/subr_rman.c:123-150 — the source even warns about multiple
   copies). **Result: the function returns non-NULL except on ENOMEM; the
   conflict check upstream relies on is structurally vacuous on DF.**
3. Compounding: DF reads the stolen base/size at early boot
   (sys/bus/pci/x86_64/pci_early_quirks.c:271-306) but the
   `phys_avail_reserve()` that would carve it out of the kernel's physical
   memory is commented out at :310-312 ("XXX: enable this once the KPI is
   available"). So on a BIOS that leaves stolen inside e820-RAM, nothing —
   neither phys_avail nor the shim — prevents the page allocator from handing
   out pages that i915 simultaneously programs the GPU to DMA over. That is
   silent kernel-memory corruption, configuration-gated (no unprivileged
   trigger; pass 1 marked pci_early_quirks.c clean, so this is recorded as
   cross-reference context from this file's side).
4. Shim-internal defects (latent, hardening): `stolen_rman.rm_end = start +
   n` manages one page beyond the region (rman end is inclusive); calling the
   shim twice re-runs `rman_init()` on the live static — duplicate
   `rman_head` entry + leaked previous `rm_slock` (subr_rman.c:87-116);
   `res` (kmalloc) is never freed; the BIOS off-by-one retry at :175-177
   underflows when `resource_size(dsm) < 2`.

## Why not reproduced / not_testable

The guest has no Intel graphics device (`/dev/dri` absent; i915 never
attaches), and the shim is pure kernel KPI (rman) — no faithful userspace
emulation exists. The security claim rests on the (certain) source facts
above plus the upstream semantics of `devm_request_mem_region` the driver
code itself documents.

## Fix

`fix.diff` (git-apply clean): single guarded `rman_init`, inclusive end
bounds, refusal of `n == 0` / wrapped ranges, keeps the kmalloc token
behavior. This repairs items 4 but cannot manufacture item 1's missing
kernel-wide conflict database — the durable fix belongs in
pci_early_quirks.c (phys_avail reservation). Recommend filing that separately
upstream of this driver.

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