DF-5430 — MADT BSP-entry omission passes probe, trips KKASSERT(arg.bsp_found) boot panic

What

sys/platform/pc64/acpica/acpi_madt.c — madt_lapic_probe() never verifies that the hardware BSP's APIC ID (from LAPIC_READID) appears among the enabled CPU entries; madt_lapic_pass2() then KKASSERT(arg.bsp_found) (acpi_madt.c:375). A crafted MADT whose enabled entries all have Id != bsp_apic_id sails through probe and panics the kernel at boot (INVARIANTS kernels). On production (non-INVARIANTS) kernels the assert is compiled out (sys/sys/systm.h:118) and the BSP silently keeps the BSS-zero cpu_id_to_apic_id[0] mapping (DF-5366's missing sentinel), mis-addressing cpu 0 whenever the hardware BSP ID is non-zero.

Rig (real kernel-boot manifestation, not a userland model)

The standard QEMU guest accepts a kenv hint that redirects the entire ACPI root: loader.conf hint.acpi.0.rsdp=0x40000000 is consumed by sdt_probe() (acpi_sdt.c:71) with no signature or checksum validation, and QEMU's -device loader,file=...,addr=0x40000000,force-raw=on plants an attacker-crafted RSDP→RSDT→MADT chain in guest RAM before boot. (-acpitable does NOT work for this: it appends after the built-in tables and sdt_search_xsdt() takes the first signature match, acpi_sdt.c:211-221.)

Build

python3 gen_madt.py bsp_omit /tmp/madt_bsp_omit.bin

Run

# guest booted normally once, then:
vm.sh run_root 'printf "hint.acpi.0.rsdp=0x40000000\n" >> /boot/loader.conf; sync'
vm.sh down
QEMU_EXTRA="-device loader,file=/tmp/madt_bsp_omit.bin,addr=0x40000000,force-raw=on" vm.sh up
vm.sh log   # watch serial console

Expected output (see run.log / run.2.log)

madt_lapic_probe: lapic_count=2 x2apic_count=0     <- probe ACCEPTS the table
panic: assertion "arg.bsp_found" failed in madt_lapic_pass2 at \
    /usr/src/sys/platform/pc64/acpica/acpi_madt.c:375

Reproduced on both guest kernel builds (Jul 2 "with-src" build and the Jun 29 clean-install build). Controls: control scenario (BSP entry present) boots through the full MADT→SMP path; see ../DF-5432 pack for a control run.

Trigger table (bsp_omit)

MADT with Address=0xFEE00000, Flags=1, and exactly two enabled LOCAL_APIC entries: {ProcessorId=1, Id=1, EN}, {ProcessorId=2, Id=2, EN} — no entry with Id == 0 (the KVM BSP's hardware APIC ID).

DF-5430 — VERDICT

1. Reproduced? YES — real kernel-boot panic, twice

Decisive lines (run.log:43-44, run.2.log:43-44):

madt_lapic_probe: lapic_count=2 x2apic_count=0
panic: assertion "arg.bsp_found" failed in madt_lapic_pass2 at /usr/src/sys/platform/pc64/acpica/acpi_madt.c:375

2. Why it is real (path:line)

• Probe aggregates only entry COUNTS: madt_lapic_probe_callback (acpi_madt.c:391-407) increments lapic_count for every enabled entry and rejects only Id == APICID_MAX. madt_lapic_probe (acpi_madt.c:453-488) checks lapic_count == 0 and the LAPIC address — it never compares any entry against the hardware BSP APIC ID that madt_lapic_enumerate obtains from LAPIC_READID (acpi_madt.c:533).
• Enumerate then runs pass2, where the only BSP sanity is KKASSERT(arg.bsp_found) (acpi_madt.c:375). On the guest's INVARIANTS kernel (sys/config/X86_64_GENERIC:56) that is an unconditional panic("assertion ...") (sys/sys/systm.h:98).
• On non-INVARIANTS kernels KKASSERT compiles to nothing (sys/sys/systm.h:118); naps is computed from the table and slot 0 keeps the BSS-zero cpu_id_to_apic_id[0] == 0 (lapic.c:122; init hole documented by DF-5366) — a hardware BSP with ID != 0 then gets every cpu-0-targeted IPI delivered to the wrong local APIC.

This is the MADT sibling of mptable's DF-5339 (probe/enumerate BSP-validation asymmetry) — same defect shape, different table.

3. Threat model / preconditions

The MADT is firmware-fed. Arming it requires control of the ACPI tables presented at boot: malicious/compromised hypervisor host, crafted UEFI firmware, a bootloader-kenv override (hint.acpi.0.rsdp=<phys>, the exact vector used here — it performs zero validation, acpi_sdp.c:71), or any console/loader access. No unprivileged in-guest path exists. Deterministic boot-time DoS (panic) on INVARIANTS kernels; silent cpu-0 mis-addressing on production kernels. Low severity per the project's accepted bar for this class (DF-1034, DF-5339).

4. Exploit chain

None — boot-time firmware-fed DoS. No memory-corruption primitive: the panic is a controlled assertion failure before any OOB write (the cpu counter stays small; the OOB-counter variant is DF-1064, not re-reported here).

5. Fix

fix.diff converts the assert into graceful enumeration failure: madt_lapic_pass2 returns EINVAL, madt_lapic_enumerate propagates it, and lapic_config() (lapic.c:1268-1272) already handles enumerate errors ("LAPIC: enumeration failed", tries the next enumerator / ENXIO) — the machine degrades instead of panicking. git apply --check passes against the read-only sys/ tree. Fix not kernel-build-validated in this run: the single mandatory build slot was spent on the memory-corruption finding DF-5432 (same-run budget; this finding is a Low boot-time panic).

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.