DF-5536 — panic-time dump walk trusts kernel page-table frames: uncontrolled OOB write / double-panic in dump_add_page

Target

sys/platform/pc64/x86_64/minidump_machdep.c (pass 2)

Build / Run (root on the guest; dumpdev required)

See build.sh / run.sh. Modes of mddiag.ko via sysctl debug.mddiag=<report|panic|maptest|booby>.

booby mode plants pdp[64] = |V in an unused kernel PDP slot (nothing live is disturbed), then panics; the crash-dump walk then processes the planted entry.

Expected

• baseline, frame 2^46: silent bit-OR into live kernel memory (bitmap+2GB) -> nested panic (vm_object_hold_shared assert), no dump.
• baseline, frame 2^47: "Fatal trap 12: page fault while in kernel mode", fault VA == predicted &vm_page_dump[frame>>18], "supervisor write data" -> nested panic, guest wedged, no dump. (panic.txt)
• patched (fix.diff): walk skips the entry, "Dump complete", savecore extracts the core. (run.patched.log)

Files

mddiag.c, fix.diff, panic.txt (2^47 fatal trap), panic.2-silent-corruption.txt (2^46), run.log (baseline), run.patched.log (fix validation), env.txt, build.sh, run.sh

Verdict — DF-5536 (REPRODUCED)

Finding

The dump walk trusts kernel page-table frames at panic time:

• minidump_machdep.c:260 — dump_add_page(pdp[i] & PG_FRAME) (the PD-page frame) and :281 — dump_add_page(pd[j] & PG_FRAME) (the PT-page frame) are not guarded by is_dumpable() (unlike the leaf-PFN paths at :271-272 and :291-292).
• dump_add_page() (:452-460) / dump_drop_page() (:463-471) perform atomic_set_long(&vm_page_dump[idx], 1ul << bit) with idx = pa >> 18 and no bounds check against vm_page_dump_size (bitmap covers only physical RAM, vm/vm_page.c:398-403).
• :263/:285 then do PHYS_TO_DMAP(frame) reads of the same unvalidated frames.

With a single corrupted PDP/PD entry (which is precisely the state a successful kernel-memory-corruption exploit leaves behind, or the residue of the very bug that caused the panic), idx is attacker-chosen: the write offset is frame >> 15 bytes past vm_page_dump, for any 52-bit frame — an uncontrolled OOB kernel write (single bit-OR, 8-byte aligned) or a kernel page fault, both during the crash-dump path.

Reproduction (baseline, fresh guest, X86_64_GENERIC 6.5-DEV)

KLD mddiag.ko plants pdp[64] = <frame>|V in an unused KVA slot (nothing live is disturbed), then panics. Two variants:

1. frame = 2^46 (panic.txt): write target vm_page_dump[2^28] = 0xfffff800c0000000 (bitmap+2 GB, mapped kernel memory) → silent bit-OR into a live kernel object → nested panic: assertion "obj != NULL" failed in vm_object_hold_shared → guest wedged, no dump.
2. frame = 2^47 (panic.2 — direct attribution): predicted target vm_page_dump[2^29] = 0xfffff80140000000 (bitmap+4 GB, unused KVA slot): Fatal trap 12: page fault while in kernel mode fault virtual address = 0xfffff80140000000 <- exactly the predicted vm_page_dump[idx] fault code = supervisor write data, page not present <- the atomic_set_long panic: page fault The fault VA matches the rig's printed &vm_page_dump[frame>>18] byte-for-byte and the fault is a supervisor write — i.e. the atomic_set_long in dump_add_page called unguarded from walk-1 line 260. No "Dump complete"; guest wedged (no reset).

Impact

Not a privilege boundary: the precondition is kernel page-table corruption (attacker is already ring-0-equivalent, or the machine is already crashing from a memory-safety bug). Consequence is loss of the crash dump exactly when it matters (evidence destroyed / availability of the dump path): the dump writer performs an uncontrolled kernel write or double-panics instead of writing the core. Severity: Low (panic-path robustness / hardening); the write primitive itself is real and demonstrated.

Fix

fix.diff (three layers): 1. is_dumpable(pdp[i] & PG_FRAME) guard before :260 (skip the whole slot); 2. is_dumpable(pd[j] & PG_FRAME) guard before :281 (skip the 2MB block — also removes the PHYS_TO_DMAP read of the bogus frame at :285); 3. bounds check pa < (vm_page_dump_size/8)*64 in dump_add_page/dump_drop_page (defense in depth; also fixes the theoretical int idx truncation for pa >= 2^49).

Validated on a patched kernel: same rig → walk skips the planted entry → "Dump complete", normal reboot, savecore extracts the core.

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.