# Verdict — DF-5535 (REPRODUCED)

## Finding
`minidumpsys()` walk-1 (sys/platform/pc64/x86_64/minidump_machdep.c:226-298) computes its
index into the `KPDPphys[]` PDP array as

    i = ((va - VM_MIN_KERNEL_ADDRESS) >> PDPSHIFT) & (NPML4EPG * NPDPEPG - 1);   (:238, :252)

but the array is `KPDPPHYS_KVA`-based and DragonFly reserves its slot 0:
`VM_MIN_KERNEL_ADDRESS = KVADDR(KPML4I, NKPML4E*NPDPEPG - NKPDPE, 0, 0)` = PDP **slot 1**
(sys/platform/pc64/include/vmparam.h:116-118; NKPML4E=16, NKPDPE=8191). The correct index
for `va` is `((va - KPDPPHYS_KVA) >> PDPSHIFT)` — exactly what the *second* walk in the
same file uses for its `kpdp` base (:385-390). Walk-1 therefore reads the PDP entry of the
1GB slot *below* `va`, and since the loop runs `va < KvaEnd` (inside slot 8191), `i` caps at
**8190**: `pdp[8191]` — the PD page covering `[0xffffffffc0000000, KvaEnd)`, the last 1 GB of
kernel VA — is **never walked**. Any page mapped only in that slot (its PD page, its PT
pages, and all data pages) is never marked in `vm_page_dump` and is silently absent from
every minidump. (Leaf-PF and 2MB paths elsewhere are unaffected; sibling walk-2 dumps the
PDP array itself correctly, so savecore sees a present-but-pageless top slot.)

## Reproduction (baseline, fresh guest, X86_64_GENERIC 6.5-DEV)
1. KLD `mddiag.ko` prints live facts: `VM_MIN_KERNEL_ADDRESS = 0xfffff80040000000`,
   `KPDPPHYS_KVA = 0xfffff80000000000` (=> VMINK = slot 1), `KERNBASE` slot 8190,
   `pdp[8190]`/`pdp[8191]` frames 0x22f0000/0x22f1000 both V=1, `walk1 max i = 8190`.
2. `sysctl debug.mddiag=maptest` maps two freshly allocated (bitmap-CLEAR) pages:
   `va1=0xffffffffd0000000` (slot 8191) and `va2=0xffffffffa0000000` (slot 8190, control),
   then panics. Real minidump written ("Dumping 680 MB ... Dump complete").
3. `dumpchk /var/crash/vmcore.1`:
   - `pa 0xaa603000` (slot 8191): **CLEAR — missing from the dump**
   - `pa 0xaae01000` (slot 8190): **SET — present**
   Identical allocation/mapping path; the only difference is the covering PDP slot.

## Impact
Silent crash-dump incompleteness for the top 1 GB of kernel VA. On the small test guest that
slot holds only scaffolding today (512 empty PTs, census in run.log), but any system whose
kernel VA grows into `[0xffffffffc0000000, VM_MAX)` (large-memory/long-uptime machines,
buffer-cache and kvm allocations) loses those pages from every crash dump — misleading
post-mortems and (weakly) anti-forensic: attacker-controlled kernel state resident in that
slot would never appear in the saved core. No privilege boundary is crossed; runs only at
panic/dump time. Severity: Low (correctness/forensics).

## Fix
`fix.diff`: index walk-1 off `KPDPPHYS_KVA` (both computations). Validated: with the patched
kernel the same maptest yields both pages SET and the dump still completes.

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