DF-5477 VERDICT — efi_get_table(): physical st_cfgtbl used as KVA + unbounded st_entries walk

Status: reproduced (KLD-harness / verbatim-copy evidence class; see rig limit). Impact: panic (deterministic fatal kernel fault on the root-reachable EFIIOC_GET_TABLE path of any conforming EFI boot) + unbounded OOB read walk (family: unvalidated firmware table, cf. DF-5430..5433 / DF-5365).

Why the bug is real (source trace)

1. sys/platform/pc64/x86_64/efirt.c:411-412 stores efi_cfgtbl = (struct efi_cfgtbl *)efi_systbl->st_cfgtbl; — raw, no PHYS_TO_DMAP, no validation. Per the EFI spec the system table's ConfigurationTable pointer is the physical address of the config table array as long as SetVirtualAddressMap() has not been called.
2. This kernel never calls SetVirtualAddressMap: rt_setvirtual (sys/efi.h:131-132) has zero call sites in the whole tree; the design comment at efirt.c:320-325 explicitly says the 1:1 mapping was chosen instead of the virtual map. The EFI loader (stand/boot/efi/loader/bootinfo.c:397) passes the firmware's systab pointer through metadata and rewrites none of its fields.
3. efi_get_table() (efirt.c:469-487) runs in normal kernel context (no efi_enter(), so the 1:1 efi pmap is NOT active), and dereferences that physical value as a kernel virtual pointer at efirt.c:480 (bcmp(&ct->ct_uuid, ...)) and advances ct++ (efirt.c:484) while count = efi_systbl->st_entries (efirt.c:477), a firmware-fed u_long with no bound of any kind.
4. On this platform the kernel direct map starts at 0xffffb80000000000 (verified empirically on the guest build); low physical addresses — where firmware tables live (my Part B used 0x7FB1C000, a typical value) — are unmapped in the kernel pmap. The first ct->ct_uuid read therefore takes a kernel-mode page fault on a "user" address with pcb_onfault == NULL → trap.c:917-926 "Fatal user address access from kernel mode" → panic. On any EFI-booted DragonFly machine, the first EFIIOC_GET_TABLE ioctl (root-only /dev/efi, efidev.c:77-84) after boot panics the kernel deterministically.
5. Independently of the fault: wherever the walk can proceed (crafted boot environment that maps low RAM, or a small st_entries lie on a system where the cfgtbl happens to be reachable), the unbounded count is an OOB read walk, and a "match" returns PHYS_TO_DMAP(ct_data) — a kernel virtual address — straight to the ioctl caller (also DF-5481).

Rig limitation (honest)

The audit guest boots legacy BIOS: efi_systbl_phys == 0, efi_init() returns ENXIO before assigning efi_systbl/efi_cfgtbl, so the in-situ production function has no inputs on this rig. Note efirt.ko still loads (MOD_LOAD error 6 is merely logged by module_register_init) and /dev/efi still appears — the surface is present, the data is not.

Evidence class therefore = KLD harness with a verbatim copy of efirt.c:469-487 (df5477_harness.c; only the two statics renamed; every expression identical). The kernel-side constants (DMAP base, fault classification, pcb_onfault semantics) are the real, running kernel's.

What was run

• Part A — sysctl debug.df5477=1: table with 2 true entries, st_entries = 200 (the lie a crafted systab feeds). Output: DF-5477A: FOUND entry 199 past table end -> returned kernel DMAP pointer 0xffffc5eadbeef000 — the walk demonstrably consumed data 4776 bytes past the table's true extent and handed a kernel DMAP VA to the caller. (run.log)
• Part B — sysctl debug.df5477=2: st_cfgtbl = 0x7FB1C000 (physical), used raw exactly as efirt.c:411-412 stores it. Output (run.2.log / panic.txt): Fatal user address access from kernel mode from sysctl, Fatal trap 12: page fault while in kernel mode, fault virtual address = 0x7fb1c000, supervisor read data, page not present, Stopped at bcmp+0x11: movq (%rdi),%r8 — the precise efirt.c:480 dereference, the precise trap.c:917-926 classification. Guest wedged in DDB; reset with vm.sh reset afterwards.

Exploit-chain assessment

Firmware/loader-fed at boot, root-gated at runtime: no unprivileged-user route. The primitive is an arbitrary-length kernel OOB read walk that also discloses kernel DMAP VAs; worst realistic outcome on a crafted boot chain is kernel-memory disclosure / boot-time fault — consistent with the family's Medium rating (cf. DF-5365 lapic_map). No escalation chain is claimed.

Fix validation

fix.diff (cap st_entries at 256 → EOVERFLOW; PHYS_TO_DMAP the physical table pointer before the walk; bounds-check ct_data). Validated by df5477_fixed.c — the same harness carrying only the fix: * lie st_entries=512 → error=84 (EOVERFLOW) ... FIX HOLDS (walk refused) * physical 0x7FB1C000 → DMAPs it to 0xffffb8007fb1c000 before deref, returned without fault. (fix_run.log). A full kernel-rebuild validation is not meaningful on this BIOS rig: the patched in-situ function has no inputs here (baseline itself is only reachable via the harness); the harness equivalence is the strongest test this rig admits.

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.