DF-5478 VERDICT — md_pages*PAGE_SIZE wrap passes the 1:1-map guard

Status: reproduced (arithmetic/model evidence class). Impact: dos (boot-time, firmware-fed, effectively unbounded kmalloc(M_WAITOK) loop → memory-exhaustion wedge at module load).

Source trace

efi_create_1t1_map() (efirt.c:198-310) walks firmware-fed EFI memory descriptors. For each EFI_MD_ATTR_RT descriptor it validates:

/* efirt.c:255-263 */
if (p->md_phys + p->md_pages * EFI_PAGE_SIZE < p->md_phys ||      /* wrap */
    p->md_phys + p->md_pages * EFI_PAGE_SIZE >= VM_MAX_USER_ADDRESS)
        goto fail;

then fills 1:1 pages:

/* efirt.c:288-297 */
for (va = p->md_phys, idx = 0; idx < p->md_pages; idx++, va += PAGE_SIZE) {
        m = kmalloc(sizeof(*m), M_EFI, M_WAITOK | M_ZERO);
        ...
        vm_page_insert(m, efi_obj, OFF_TO_IDX(va));
}

The guard only tests the computed end pointer. md_pages (uint64_t, sys/efi.h:75) is never bounded directly, so when md_pages * 4096 itself wraps mod 2^64 to a small value W, the end pointer falls back into [md_phys, VM_MAX_USER_ADDRESS) and the guard passes — while the loop bound remains the wrapped-around md_pages:

• md_pages = 2^52 → product ≡ 0 → end == md_phys → PASS → 4.5e15 iterations
• md_pages = 2^52 + 1 → product ≡ 4096 → end == md_phys+4096 → PASS
• generally any md_pages = (W + k*2^64)/4096 with small W and low md_phys

Each iteration kmallocs a struct vm_page (~88 bytes) with M_WAITOK. At MOD_LOAD time (SI_SUB_DRIVERS, efirt.c:635) nothing will ever free those allocations; the loop cannot be killed; the allocator exhausts RAM and M_WAITOK sleep-forevers under pressure. Boot wedges. (Trigger is a crafted EFI memory map — firmware- or loader-fed — the unvalidated-table family; runtime reachability does not exist.)

Reproduction

df5478_wrap.c (guest, cc -O2, run as root/user — pure userspace model of the exact production arithmetic): see run.log —

wrap: md_pages = 2^52     product=0x0      end=0x0000000001000000  guard: PASS (BUG)
    -> fill-loop iterations=4503599627370496 (4.5e+15), kmalloc(M_WAITOK) bytes > 3.69e+08 GiB
wrap: md_pages = 2^52+1   product=0x1000   end=0x0000000001001000  guard: PASS (BUG)
no-wrap 2^40 pages        product=0x0010000000000000                       guard: REJECT (correct)

(In the "sane 256 pages" control the guard also PASSes and the loop runs — that is correct behavior there; only the wrap rows are the bug.)

Rig limit (honest)

BIOS-boot guest: efi_init() returns ENXIO at the missing MODINFOMD_EFI_MAP metadata (efirt.c:421-427) long before efi_create_1t1_map() runs, so the in-situ loop cannot be driven. The model uses identical integer widths and constants; nothing in the loop/guard depends on kernel-only semantics beyond M_WAITOK availability.

Fix validation

fix.diff adds the direct page-count cap p->md_pages >= VM_MAX_USER_ADDRESS / EFI_PAGE_SIZE ahead of the existing checks. The model's FIXED-guard section (same run.log) shows the wrap rows now REJECT ("loop never starts") while the sane 256-page case is still accepted — the previously-demonstrated bad arithmetic no longer passes. Kernel-rebuild validation is not meaningful on this rig (the vulnerable statics/path have no inputs on a BIOS boot); the arithmetic 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.