DF-5365 — lapic_map() adopts firmware LAPIC physical address with no validation → boot-time arbitrary-physical-address kernel read/write

Verdict

REPRODUCED (boot-time, firmware-data-gated kernel memory corruption; not userspace-reachable). Fix VALIDATED on a single-fix kernel: with fix.diff, lapic_map() cross-checks the firmware value against IA32_APICBASE and falls back to the hardware page; the identical harness run then writes 0/7 cells of the attacker page and leaves cpu_id_to_apic_id[3] untouched, while printing LAPIC: bogus LAPIC address 0x… in firmware table, using 0xfee00000 from APIC base MSR.

Mechanism (every hop cited)

lapic_map() at sys/platform/pc64/apic/lapic.c:1081-1085:

void
lapic_map(vm_paddr_t lapic_addr)
{
    lapic_mem = pmap_mapdev_uncacheable(lapic_addr, sizeof(struct LAPIC));
}

lapic_addr is firmware-supplied on both enumeration paths:

• MADT: madt_lapic_probe seeds arg.lapic_addr = madt->Address (acpi_madt.c:451); madt_lapic_pass1 returns it, honoring LOCAL_APIC_ADDRESS_OVERRIDE entries (acpi_madt.c:~250-270); the only special-cased value anywhere on the path is 0 (acpi_madt.c:479-487 — and only when the CPU lacks x2APIC). madt_lapic_enumerate then calls lapic_map(lapic_addr) (acpi_madt.c:528-531).
• MP table: lapic_addr = cth->apic_address (mptable.c:761, KKASSERT(lapic_addr != 0) only) → lapic_map(lapic_addr) (mptable.c:805).

The CPU's own MSR_APICBASE (0x1b, specialreg.h:533) always contains the real page base (0xFEE00000 on this guest) and is never consulted.

After the mapping, lapic_init() (lapic.c:272-408) performs RMW stores to lvt_lint0/lint1/error/pcint/timer, tpr, svr, plus three stores of 0 to eoi; lapic_timer_calibrate() arms icr_timer with APIC_TIMER_MAX_COUNT (0xffffffff, lapic.c:451/:493/:542/:591) and writes the divisor to dcr_timer (lapic.c:440). Every store lands at a fixed offset (eoi +0xB0, svr +0xF0, icr_timer +0x380, dcr_timer +0x3E0, lvt_* +0x320..0x370) inside the page the firmware table selected. Reads (LAPIC_READID at enumeration, LAPIC_READ(version) at lapic.c:330/380) return page contents the attacker also controls (info side-channel / logic steering).

What was demonstrated on the guest (stock kernel #0, Jul 2 snapshot)

KLD harness df5365.ko (root kldload; the established evidence class for boot-path bugs on this rig — same as DF-1064, since -acpitable cannot override QEMU's built-in MADT, sdt_search() returns the first match):

• Test A — lapic_map(phys_of_fresh_RAM_page) (production call), page pre-filled 0xAAAAAAAA: LAPIC_MEM_READ(version) returned 0xAAAAAAAA (READ primitive), and the lapic_init() store set rewrote 7/7 observed register cells (run.log): eoi=0, icr_timer=0xffffffff, dcr_timer=0x00, svr=0xaaaaa9ff (fill|APIC_SVR_ENABLE|vector), lint0/lint1/timer RMWed.
• Test B — lapic_map(phys(&cpu_id_to_apic_id[3]) - 0x380) so the oneshot-arm store aliases the live BSS array: cpu_id_to_apic_id[3] went 0x00000003 → 0xffffffff (KERNEL-BSS CORRUPTION CONFIRMED), then restored.

The guest stayed healthy through load/unload in both baseline runs (run.log, run.2.log).

Threat model / impact ceiling

Precondition is control of the firmware tables presented at boot (crafted MADT via patched BIOS/pflash; MADT injection with -acpitable does NOT reach the sink because the kernel picks the first APIC-signature table). This is the same premise already accepted for DF-1042 (Medium) and DF-1064 (High). Within that premise the primitive is stronger than DF-5341 (mptable arbitrary-PA read): it is an arbitrary-PA write page whose fixed-offset stores include full-control values 0 and 0xffffffff and preserving RMWs — enough to corrupt kernel text/data/heap in physical memory at boot (e.g., zero a syscall table entry, forge pointer halves with RMW bit-sets) and to read boot-time kernel memory through LAPIC_READs (version/ID steering). Requires memory-mapped LAPIC mode (x2apic_enable == 0).

Fix validation (kernel #1, fix.diff)

fix.diff adds the missing cross-check in lapic_map(): derive hw_addr = rdmsr(MSR_APICBASE) & ~0xFFF and fall back to it (with a kprintf) whenever the firmware value is 0, misaligned, or differs. Applied to the guest /usr/src, make -j6 nativekernel KERNCONF=X86_64_GENERIC, installed, rebooted (clean boot: normal LAPIC: enter X2APIC mode, no warning on the genuine path). Identical harness run (fix_run.log, fix_run.2.log):

• Test A: LAPIC: bogus LAPIC address 0xd9d8000 … using 0xfee00000 from APIC base MSR; 0/7 cells written; attacker page still 0xAAAAAAAA; version read returns 0xffffffff (real MMIO, architecturally ignored in x2APIC mode — not the attacker fill).
• Test B: LAPIC: bogus LAPIC address 0x18d9dac …; cpu_id_to_apic_id[3] stays 0x00000003 — not-confirmed.

Harness debugging notes (poc_changes)

The first harness revision passed the modevent function as DECLARE_MODULE's data argument (must be a moduledata_t struct). That made module_register() treat function bytes as a moduledata_t and strcmp a code-bytes "pointer" → GPF strcmp+0x10 (dump captured on the serial log). Fixed by declaring static moduledata_t df5365_mod = {"df5365", df5365_modevent, NULL}; exactly as DF-1064's harness does. Test B was also strengthened after the first successful run (initial variant aliased an already-zero cell; final variant aliases cpu_id_to_apic_id[3] (value 3) with the 0xffffffff store for an unambiguous 3 → 0xffffffff flip).

Artifacts

• df5365_harness.c — KLD harness (production lapic_map() + production store set; saves/restores state)
• gen_madt.py — conceptual malicious MADT (LocalApicAddr = 0x01000000)
• build.sh / run.sh — exact commands
• build.log — full successful build (baseline)
• run.log, run.2.log — baseline reproductions (stock kernel #0)
• fix_run.log, fix_run.2.log — patched-kernel runs (fix rejected both attacker addresses; no corruption)
• env.txt — guest uname/tunables/compiler
• fix.diff — validated fix (git-apply-able vs this tree; never applied to the read-only audit sys/)

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.