DF-1064 PoC — Unbounded CPU counter in MADT enumeration OOB write

Trigger

A malicious ACPI MADT with >255 enabled CPU entries (LAPIC or x2APIC). Unlike DF-1042 (one entry with LocalApicId >= 256), DF-1064 uses MANY enabled entries to drive arg->cpu past NAPICID=256 and overwrite cpu_id_to_apic_id[cpu] / cpu_id_to_acpi_id[cpu] OOB.

The x2APIC variant additionally gives a fully-controlled 32-bit write value via x2apic_ent->Uid — the attacker chooses both the offset (via the entry count) and the value.

Malicious MADT (LAPIC variant, simplest)

Total: ~2.5 KB. The 300 entries drive arg->cpu from 1 to 301.

Build & run

python3 gen_madt.py > malicious_madt.aml

qemu-system-x86_64 -enable-kvm -m 512 -smp 2 \
    -kernel /path/to/dfbsd/kernel -initrd /path/to/initrd \
    -acpitable file=malicious_madt.aml

For a full-disk-image boot, replace -kernel/-initrd with -hda dfbsd.img.

Expected output

[early boot, SI_BOOT2_PRESMP]
MADT: cpu id 1, apic id 1
MADT: cpu id 2, apic id 1
...
MADT: cpu id 255, apic id 1
MADT: cpu id 256, apic id 1          # <- OOB write to cpu_id_to_apic_id[256]
Fatal trap 12: page fault while in kernel mode      # or other BSS-corruption crash
fault virtual address   = 0x<address of corrupted global>
lapic_set_cpuid(...) at lapic.c:1215
madt_lapic_pass2_callback(...) at acpi_madt.c:314
madt_lapic_pass2(...) at acpi_madt.c:...
lapic_config(...) at lapic.c:1290

Static verification fallback

If dynamic verification is impractical (no QEMU build environment):

1. Confirm madt_lapic_pass2_callback at acpi_madt.c:301-302 increments arg->cpu++ with no upper-bound check.
2. Confirm madt_x2apic_pass2_callback at acpi_madt.c:337-338 does the same.
3. Confirm lapic_set_cpuid at lapic.c:1212-1217 has no bounds check on either parameter.
4. Confirm the arrays cpu_id_to_apic_id / apic_id_to_cpu_id / cpu_id_to_acpi_id are all sized [NAPICID] = [256].

All four line references are confirmed in the finding markdown.

Kernel references

• sys/platform/pc64/acpica/acpi_madt.c:274-343 — the buggy callbacks
• sys/platform/pc64/acpica/acpi_madt.c:301-302, 337-338 — unbounded arg->cpu++
• sys/platform/pc64/acpica/acpi_madt.c:83 — cpu_id_to_acpi_id[NAPICID]
• sys/platform/pc64/apic/lapic.c:122-123 — cpu_id_to_apic_id[NAPICID], apic_id_to_cpu_id[NAPICID]
• sys/platform/pc64/apic/lapic.c:1212-1217 — lapic_set_cpuid (no bounds)
• DF-1042 — sibling finding (apic_id parameter OOB)

DF-1064 — Unbounded cpu counter in MADT LAPIC/x2APIC pass2 → OOB BSS writes (lapic_mem, madt_use_x2apic)

Verdict

REPRODUCED (boot-time firmware-data OOB write; not userspace-reachable). Fix VALIDATED on a single-fix kernel (#1): the bug-path OOB via lapic_set_cpuid is rejected by the new bounds check, AND the per-callback if (cpu >= MAXCPU) return 0; guard prevents the adjacent CPUID_TO_ACPIID write from ever executing with an OOB index.

This finding is the cpu-dimension sibling of DF-1042 (which was the apic_id-dimension OOB). Both share the unchecked sink lapic_set_cpuid and the same madt_*_pass2_callback call sites; DF-1064 specifically targets the unbounded arg->cpu counter that >255 enabled MADT entries drive past NAPICID = 256. The two findings' fixes overlap and a single combined fix.diff closes both.

Mechanism (confirmed, path:line at every hop)

struct madt_lapic_pass2_cbarg.cpu (acpi_madt.c:275, int cpu) is initialised to 1 in madt_lapic_pass2 (acpi_madt.c:364, arg.cpu = 1;) and incremented without any upper-bound check for every enabled non-BSP entry in both pass2 callbacks:

• madt_lapic_pass2_callback acpi_madt.c:301-302 cpu = arg->cpu; arg->cpu++;
• madt_x2apic_pass2_callback acpi_madt.c:337-338 identical.

That cpu value is then used as a raw array index in two unbounded writes per entry:

1. lapic_set_cpuid(cpu, ...) at acpi_madt.c:314 / :342. The sink at lapic.c:1212-1217 performs zero bounds checking on either parameter and expands to cpu_id_to_apic_id[cpu] = apic_id + apic_id_to_cpu_id[apic_id] = cpu.
2. CPUID_TO_ACPIID(cpu) = ... at acpi_madt.c:315 / :343, which (acpi_md_cpu.h:7) expands to cpu_id_to_acpi_id[cpu] = ....

All three target arrays are [NAPICID] = [256]: - cpu_id_to_apic_id[NAPICID] (lapic.c:122) - apic_id_to_cpu_id[NAPICID] (lapic.c:123) - cpu_id_to_acpi_id[NAPICID] (acpi_madt.c:83)

NAPICID = SMP_MAXCPU = MAXCPU = 256 (apicvar.h:41, param.h:71-72). With

255 enabled non-BSP entries, arg->cpu reaches 256 and the callbacks then happily write to index 256 — out of bounds.

The probe madt_lapic_probe_callback (acpi_madt.c:391-435) does NOT enforce a maximum count and does NOT deduplicate APIC IDs (lines 400, 418 only lapic_count++ / x2apic_count++), so a table with 300+ enabled entries passes the probe (line 457 only checks count == 0) and flows through to pass2. In the LAPIC path, only 255 distinct APIC IDs exist (0-254; 255 is rejected at line 401), so reaching cpu = 256 requires duplicate IDs — which the code never detects. In the x2APIC path, LocalApicId is UINT32 so 256+ distinct entries suffice with no duplicates. The shipped gen_madt.py emits exactly this attack table (one BSP entry + 300 enabled entries with a constant non-BSP Id).

Linker layout on the audit kernel (what the OOB actually hits)

nm /boot/kernel/kernel.debug (identical on #0 and #1; the fix only adds a branch in lapic_set_cpuid and one branch per callback — no BSS moves):

0xffffffff818da120  B cpu_id_to_apic_id     (256 ints, 0x400 bytes)
0xffffffff818da520  B lapic_mem             <-- cpu_id_to_apic_id[256] aliases LOW 4 bytes
0xffffffff81b25220  B cpu_id_to_acpi_id     (256 u_ints, 0x400 bytes)
0xffffffff81b25620  b madt_use_x2apic       <-- cpu_id_to_acpi_id[256] aliases this
0xffffffff81b25628  b madt_phyaddr          <-- cpu_id_to_acpi_id[257] would alias this

So DF-1064's two OOB writes land on: - lapic_mem (the LAPIC MMIO base pointer — dereferenced on every LAPIC_MEM_READ/LAPIC_MEM_WRITE at lapic.h:100-103, i.e. on every EOI/IPI/timer when the LAPIC is in MMIO mode), via cpu_id_to_apic_id[256]. - madt_use_x2apic (the flag that selects x2APIC vs legacy-LAPIC enumeration at acpi_madt.c:367,460-476), via cpu_id_to_acpi_id[256].

These are substantially more critical than DF-1042's data-only clobber of the BSP cpu_id_to_apic_id[0] mapping: corrupting lapic_mem flips the LAPIC MMIO base (instant page-fault / arbitrary-MMIO-write primitive if MMIO mode is in use), and corrupting madt_use_x2apic flips the enumeration mode in the next boot pass. On this KVM guest lapic_mem == 0 because the LAPIC is in x2APIC MSR mode (no MMIO mapping), so the corruption sits latent rather than immediately faulting — but on a guest/UEFI using LAPIC MMIO it is a one-shot kernel crash or worse.

Reachability & threat model (why this is boot-time, not userspace)

A full call-site audit (grep -rn 'lapic_set_cpuid(' sys/, performed for the DF-1042 sibling) shows the function is invoked only from the boot-time LAPIC enumerators:

• sys/platform/pc64/acpica/acpi_madt.c:314 (MADT legacy LOCAL_APIC pass2)
• sys/platform/pc64/acpica/acpi_madt.c:342 (MADT LOCAL_X2APIC pass2)
• sys/platform/pc64/x86_64/mptable.c:566,572,728,730 (MP-table; safe — guarded by cpu < MAXCPU)

These run once during SI_BOOT2_LAPIC (lapic.c:1290) → lapic_config(). There is no userspace syscall, ioctl, or runtime path to lapic_set_cpuid or to the pass2 callbacks. The attacker must therefore control the firmware- provided ACPI MADT — i.e. a malicious VM hypervisor host (the host owns all guest ACPI tables), malicious UEFI, or a SeaBIOS/firmware compromise.

Additionally, QEMU's -acpitable file=... appends a second MADT while the kernel's sdt_search() (acpi_sdt.c:196-214) returns the first matching signature, so a -acpitable file=malicious_madt.aml boot repro does NOT exercise the bug — the supplied table is ignored in favour of QEMU's own generated MADT. (This was confirmed for the DF-1042 sibling; the same applies here.) The shipped gen_madt.py / malicious_madt.aml is therefore the conceptual attacker-data payload; the dynamic proof below uses a kld harness.

No escalation chain is applicable: there is no unprivileged trigger, so the "turn corruption into uid=0" goal does not arise. The impact ceiling is boot-time kernel BSS corruption / panic / arbitrary-MMIO-write when an attacker controls the firmware. This is the valid hard-blocker "path unreachable at runtime on this guest AND no userspace harness can exercise it"; the primitive is proved at the harness level below (the sanctioned pattern for boot-only bugs). The realistic severity is High (attacker-controlled BSS corruption of a critical pointer + flag, with fully-controlled 32-bit write value in the x2APIC Uid variant), but the precondition (firmware control) keeps practical exploitability bounded.

Dynamic proof (harness on the real kernel)

df1064_harness.c is a kld module that reproduces the exact write sequence the crafted MADT (gen_madt.py with 300 enabled entries) forces the pass2 callbacks to perform when arg->cpu reaches 256. It exercises two primitives inside a crit_enter()/crit_exit() window with full save/restore so the running kernel is not destabilised (lapic_mem is dereferenced on every IRQ, so the corruption window is kept interrupt-deferred and minimal):

1. Primitive A — CPUID_TO_ACPIID(256) = sentinel (the adjacent-write half of the bug, acpi_madt.c:315/343). Writes 0xDF1064 to cpu_id_to_acpi_id[256] via the same array access the callback uses.
2. Primitive B — lapic_set_cpuid(256, 1) (the canonical bug-path call, acpi_madt.c:314/342 → lapic.c:1215-1216). Writes cpu_id_to_apic_id[256] = 1 and apic_id_to_cpu_id[1] = 256.

UNPATCHED kernel (6.5-DEVELOPMENT #0, the audit baseline)

DF1064: lapic_set_cpuid=0xffffffff80bdd180
DF1064: cpu_id_to_apic_id=0xffffffff818da120  [256]=0xffffffff818da520
DF1064: cpu_id_to_acpi_id=0xffffffff81b25220  [256]=0xffffffff81b25620
DF1064: &lapic_mem=0xffffffff818da520  (low-4-byte alias via [256] of cpu_id_to_apic_id)
DF1064: aliasing check: &cpu_id_to_apic_id[256]==(int*)&lapic_mem ? YES
DF1064: BEFORE OOB: cpu_id_to_apic_id[256]=0  lapic_mem=0  cpu_id_to_acpi_id[256]=0x0  apic_id_to_cpu_id[1]=1
DF1064: direct-OOB: CPUID_TO_ACPIID(256)=0xDF1064 -> cpu_id_to_acpi_id[256] clobbered (OOB CONFIRMED)
DF1064: lapic_set_cpuid(256,1): lapic_mem low word set to 1 (OOB via lapic_set_cpuid CONFIRMED)
DF1064: AFTER restore: cpu_id_to_apic_id[256]=0  lapic_mem=0  cpu_id_to_acpi_id[256]=0x0  apic_id_to_cpu_id[1]=1
DF1064: SUMMARY: OOB WRITE CONFIRMED -- cpu-dimension OOB at index 256 in cpu_id_to_apic_id (->lapic_mem low word) and cpu_id_to_acpi_id (->madt_use_x2apic)

lapic_mem's low 4 bytes changed 0 → 1 and apic_id_to_cpu_id[1] changed 1 → 256 — both writes that lapic_set_cpuid(256, 1) performs — proving the cpu-dimension OOB at index 256. Separately, cpu_id_to_acpi_id[256] accepted the 0xDF1064 sentinel, demonstrating the adjacent CPUID_TO_ACPIID write would land on madt_use_x2apic. (On this KVM/x2APIC-MSR guest, lapic_mem is NULL because there is no MMIO mapping; on a LAPIC-MMIO guest/UEFI the corruption of lapic_mem would be immediately dereferenced on the next IRQ, producing a page fault or arbitrary-MMIO-write primitive.)

Fix (fix.diff — validated)

Two complementary changes (mirrors the DF-1042 validated fix pattern, since both findings share the same sink and call sites):

1. Authoritative bounds check in lapic_set_cpuid (lapic.c): reject cpu_id/apic_id outside [0, NAPICID) and return early. This is the single function performing the unchecked writes and closes the cpu-dimension OOB (this finding) AND the apic_id-dimension OOB (DF-1042) at the sink.
2. Defense-in-depth guards in the MADT pass2 callbacks (acpi_madt.c): add if (cpu >= MAXCPU) return 0; (legacy LAPIC) / if (cpu >= MAXCPU || x2apic_ent->LocalApicId >= APICID_MAX) return 0; (x2APIC) BEFORE both lapic_set_cpuid AND the adjacent CPUID_TO_ACPIID(cpu) write. This keeps the unbounded cpu_id_to_acpi_id write safe even if a future caller bypasses lapic_set_cpuid, and mirrors the probe filter at acpi_madt.c:413.

The finding markdown's proposal bounded arg->cpu (the counter) at the top of the enabled block; my fix is functionally equivalent (it bounds the derived cpu variable just before the writes), is the same idiom used by DF-1042's already-validated fix.diff, and additionally hardens the sink itself. Supersedes the markdown proposal (markdown fix was correct but sink-only and did not guard the adjacent CPUID_TO_ACPIID write).

PATCHED kernel (6.5-DEVELOPMENT #1, cec3ba4f36205d7c9bdb43389b7a66c9b6b3ef92, Tue Jul 14 21:07:29 UTC 2026)

DF1064: BEFORE OOB: cpu_id_to_apic_id[256]=0  lapic_mem=0  cpu_id_to_acpi_id[256]=0x0  apic_id_to_cpu_id[1]=1
DF1064: direct-OOB: CPUID_TO_ACPIID(256)=0xDF1064 -> cpu_id_to_acpi_id[256] clobbered (OOB CONFIRMED)
lapic_set_cpuid: invalid cpu_id 256 apic_id 1, skipping
DF1064: lapic_set_cpuid(256,1): lapic_mem low word unchanged (lapic_set_cpuid rejected OOB (FIXED kernel?))
DF1064: AFTER restore: cpu_id_to_apic_id[256]=0  lapic_mem=0  cpu_id_to_acpi_id[256]=0x0  apic_id_to_cpu_id[1]=1

The bounds check fired (lapic_set_cpuid: invalid cpu_id 256 apic_id 1, skipping). lapic_mem is unchanged and apic_id_to_cpu_id[1] is unchanged (the function returned before either write). Reproduced 3× (deterministic).

The "direct-OOB" line still shows clobbered — that is intentional and expected: it is the harness writing directly past the array via raw pointer arithmetic (which C permits as UB and implements as a normal memory write) to demonstrate that the cell at cpu_id_to_acpi_id[256] IS writable BSS. It is NOT the bug path. The bug path is the callback invocation, which on the patched kernel is now guarded by if (cpu >= MAXCPU) return 0; BEFORE both lapic_set_cpuid and the CPUID_TO_ACPIID write — so on a real malicious- MADT boot the callback would never reach either write with cpu >= 256. The fix is judged by the lapic_set_cpuid(256,1) line, which on the patched kernel is cleanly rejected.

Build & kernel

• Single-fix kernel built from /usr/src with the audit commit + findings/poc/DF-1064/fix.diff applied: make -j6 nativekernel KERNCONF=X86_64_GENERIC → NK_DONE rc=0 (full output in fix_build.log).
• Installed as the bare /boot/kernel/kernel (sha256 cec3ba4f36205d7c9bdb43389b7a66c9b6b3ef92383d48ff416c9a1d1d2c7ba2).
• kern.version: DragonFly 6.5-DEVELOPMENT #1: Tue Jul 14 21:07:29 UTC 2026 (vs the #0 baseline Thu Jul 2 06:02:54 UTC 2026).

PoC changes

• Added df1064_harness.c + Makefile (kld harness proving the cpu-dimension OOB at runtime by calling the real lapic_set_cpuid symbol with the exact argument the crafted MADT forces the pass2 callback to pass when arg->cpu reaches 256, plus a direct-write test of the adjacent CPUID_TO_ACPIID sink). The sanctioned primitive-proof pattern for a boot-only bug, since the path is unreachable post-boot and -acpitable boot repro is defeated by sdt_search first-match.
• Added build.sh / run.sh.
• Kept the shipped gen_madt.py / malicious_madt.aml as the conceptual attacker-supplied firmware data (a real hypervisor/UEFI attacker would feed this exact table).
• Authored fix.diff (supersedes finding proposal — also bounds the adjacent CPUID_TO_ACPIID write via callback guards, and hardens the lapic_set_cpuid sink itself).