VERDICT — DF-5358

Status: reproduced (impact: panic — root-gated local DoS via /dev/kmem read; confidence: certain) Fix: validated (fix_status=fixed — panic eliminated, clean EFAULT, no regression).

What was claimed

Pass-2 audit of sys/platform/pc64/x86_64/vm_machdep.c flagged kvm_access_check() (vm_machdep.c:1276-1291) as the pc64 consumer of a pmap_kextract() (pmap.c:1865-1888) that performs no paging-level validity check — the pc64 twin of DF-5245 (pmap_extract, "no live in-tree KVA caller") and DF-5290 (vkernel pmap_extract/pmap_kextract, whose live caller is the vkernel kvm_access_check). Two predicted failure modes:

1. ungrown KVA → *vtopt(va) recursive-map deref → kernel page fault → panic;
2. PT-present/PTE-0 → non-zero garbage → "pages resident" gate passes vacuously.

How it was proven (guest: DragonFly 6.5-DEVELOPMENT #0 Jul 2 2026, X86_64_GENERIC)

Baseline (stock kernel)

pmxtest.ko (build.sh, root):

pmxtest: KvaStart=fffff80040000000 KvaEnd=ffffffffff1ff000 KvaSize=000007ffbf1ff000
pmxtest[1]: CONTROL pmap_kextract(&dummy=0xffffffff826002d8) = 0000000135ab1278 (mapped, sane)
pmxtest[2]: va=ffffffff82601000 while-mapped pa=0000000134641000
pmxtest[2]: PT-present/PTE-0: aligned   pmap_kextract(va)     = 0000000000000000
pmxtest[2]: PT-present/PTE-0: unaligned pmap_kextract(va+0x30) = 0000000000000030  <-- garbage
pmxtest[2]: restored + freed
pmxtest[3]: kernel_vm_end=fffff80118800000
pmxtest[3]: PML4[496] present, PDPT[5] ABSENT (0000000000000000) -> /dev/kmem test KVA fffff80140000000

• The PTE-0 hole is manufactured deterministically: kmem_alloc3() one page, pmap_kremove() its PTE (kernel PT pages are never freed, so the level above stays present), extract, restore, free.
• Honest correction to the initial analysis: for the aligned addresses kvm_access_check() walks, (pa & PG_FRAME)|(va & PAGE_MASK) evaluates to 0 (offset-in-page is 0), so the aligned PTE-0 case actually fails closed on pc64. The non-zero garbage appears only for unaligned callers (0x30 observed) — exactly the DF-5245 defect class, but those in-tree callers (kern_memio.c:784/797/821 user_kernel_mapping) only query always-mapped kernel objects. So failure mode 2 is a latent landmine on pc64 today, not a live gate bypass.
• Failure mode 1 is live and lethal. pmx_user (pread /dev/kmem, 8 bytes) at the probed absent-PDPT KVA 0xfffff80140000000 (inside [KvaStart,KvaEnd), above kernel_vm_end, covered by the VM_SUBSYS_RESERVED VM_PROT_ALL entry kmem_init() (vm_kern.c:494-537) installs over all unallocated KVA — so kernacc() would NOT have rejected it either):

Fatal user address access from kernel mode from pmx_user at ffffffff80c0cdc6
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0xffff80403e005000     <- recursive-map PDE-slot address (unmapped)
fault code           = supervisor read data, page not present
current process      = 1016
Stopped at pmap_kextract.part.23+0x16: movq (%rax,%rdx,1),%rdx

Call chain: pread → mmrw (kern_memio.c:257-290, minor 1) → kvm_access_check (vm_machdep.c:1284 loop) → pmap_kextract (pmap.c:1872 pt = *vtopt(va)) → page fault, pcb_onfault == NULL → db> panic. Guest down. REPRODUCED.

Reachability gating: /dev/kmem open requires caps_priv_check(SYSCAP_RESTRICTEDROOT|__SYSCAP_NOROOTTEST) (kern_memio.c:152); reads are allowed at any securelevel/kernel_mem_readonly (only FWRITE is blocked, kern_memio.c:155-158). So the panic is root-gated, not securelevel-gated. Impact ceiling: privileged local DoS (Low per the audit rubric). No memory-corruption primitive: the faulting access is a read of an unmapped address inside the validator itself; the garbage-PA variant returns a bogus PA that pc64 kvm_access_check only compares against 0 (it is not used as a DMA target), and the aligned walk fails closed. No uid=0 chain exists or was pursued (triggering already requires root).

Fix validation

fix.diff replaces the recursive-map deref with a DMAP walk of the four levels with PG_V required at each (returning 0 when absent). Applied to the guest's /usr/src (patch -p1), make -j6 nativekernel KERNCONF=X86_64_GENERIC + make installkernel (rc=0, Werror clean), reboot.

An intermediate fix (v1) skipped the PDPT→PD level (fed the PDPE to pmap_pt_to_pte) and panicked at boot (vm_page_free_contig: wire_count == 1 via ata_dmaalloc) — my authoring bug, not a kernel issue; recorded here for honesty. The final fix.diff (v2) walks all four levels.

Patched kernel (build #1 Oct 3 2026):

pmxtest[1]: CONTROL pmap_kextract(&dummy=...) = 000000013218e2d8      (sane)
pmxtest[2]: PT-present/PTE-0: unaligned pmap_kextract(va+0x30) = 0000000000000000   (garbage gone)
pmxtest[3]: ... -> /dev/kmem test KVA fffff80140000000
$ ./pmx_user 0xfffff80140000000 8
pmx_user: pread returned -1 errno=14 (Bad address)
pmx_user: kernel survived (no panic)
$ ./pmx_user 0xffffffff811449e0 24        # control: kernel `version` symbol
pmx_user: pread returned 24 errno=0        # /dev/kmem still reads mapped KVA

Baseline panic eliminated; clean EFAULT; no false negatives on mapped KVA; the whole system boots and runs (vtophys() == pmap_kextract(), so every busdma/ contigfree path exercised the new walk during boot + build).

Why the other cited paths in the file are clean (pass-2 negative results)

• cpu_fork LDT paths (vm_machdep.c:118-123, 221-227) — dead on pc64: pcb_ldt has no writer; user_ldt_alloc/free/set_user_ldt are panic stubs (userldt.c:42-58); sysarch.c has no LDT ops on x86_64.
• cpu_fork PCB copy — union savefpu pcb_save is embedded in struct pcb (pcb.h:80) and td_savefpu = &td_pcb->pcb_save (pmap.c:2250), so *pcb2 = *pcb1 copies FPU state by value with no aliasing; pcb_ext is NULLed (vm_machdep.c:218) and never set on pc64 (cpu_lwp_exit's KKASSERT at :311 can't fire); pcb_onfault is NULL in fork context.
• cpu_prepare_lwp's user-controlled copyout (vm_machdep.c:262-265) — std_copyout (support.s:228-279) rejects dst/len outside user range (carry + VM_MAX_USER_ADDRESS), so a kernel-range lwp_stack returns EFAULT, not a write.
• PCB_DBREGS/dbregs — set_dbregs (machdep.c:3133) re-validates addresses vs VM_MAX_USER_ADDRESS for unprivileged users; fork inheritance copies within identical credentials (no privilege crossing); swtch.s:210-236/592-618 save/restore protocol is flag-consistent with cpu_lwp_exit's reset_dbregs (vm_machdep.c:316-319).
• spectre/mds sysctl parsers (vm_machdep.c:654-752, 1045-1146) — root-only (kern_sysctl.c:1447 SYSCAP_NOSYSCTL_WR), 128-byte buffer with len >= sizeof(buf) rejection and NUL termination; strsep loop safe.
• cpu_vmspace_alloc/free — empty stubs on pc64 (vm_machdep.c:1266-1273); the VMSPACE_CTL_* intercept lives in vm_vmspace.c (already pass-2 audited).
• kernacc int-truncation at vm_machdep.c:1288 (eaddr - saddr → int param of kernacc) — real type defect, but unreachable in isolation: any /dev/kmem transfer ≥ 2^31 spans unmapped KVA, so the (correct or panicking) page walk decides first; with a correct walk it returns EFAULT before kernacc's truncated length matters. Killed (negative note), consistent with DF-0081's INVALID resolution of the uiomove side.

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.