DF-1042 PoC — lapic_set_cpuid OOB write via crafted MADT

Trigger

Crafted ACPI MADT table containing x2APIC entries that exercise the missing bounds check in lapic_set_cpuid(). Two variants:

Variant A — large LocalApicId

Generate a MADT with one BSP entry that has LocalApicId=0 (passes probe phase) and one entry with LocalApicId=256 (triggers OOB write at apic_id_to_cpu_id[256]).

Variant B — many enabled entries

Generate a MADT with 257+ enabled LOCAL_APIC entries; the cpu counter reaches 256 and cpu_id_to_apic_id[256] is written OOB.

Generate the MADT

gen_madt.py emits a minimal MADT table with the header, one LAPIC address override, the BSP x2APIC entry, and one malicious x2APIC entry with LocalApicId=256. Output is ready for QEMU's -acpitable file=....

The MADT subtable layout (ACPI_MADT_LOCAL_X2APIC): - Type (u8) = 9 (LOCAL_X2APIC) - Length (u8) = 16 - Reserved (u16) - LocalApicId (u32) ← attacker-controlled - Uid (u32) - LapicFlags (u32) bit 0 = ENABLED

Run:

python3 gen_madt.py > malicious_madt.aml

Run under QEMU

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

Expected output (Variant A)

[early boot]
MADT: cpu id 0, acpi uid 0, apic id 0
MADT: cpu id 1, acpi uid 1, apic id 256
Fatal trap 12: page fault while in kernel mode
fault virtual address   = 0x<address past apic_id_to_cpu_id>
lapic_set_cpuid(...) at lapic.c:1216
madt_x2apic_pass2_callback(...) at acpi_madt.c:342
madt_lapic_pass2(...) at acpi_madt.c:...
lapic_config(...) at lapic.c:1290

Notes

• This is a boot-time firmware-data trigger, not a userspace exploit. The "attacker" must control the firmware/ACPI tables (malicious VM host, malicious UEFI, or a SeaBIOS patch).
• An alternate proof without QEMU is a unit test that constructs a fake ACPI_MADT_LOCAL_X2APIC and calls madt_x2apic_pass2_callback directly with LocalApicId >= 256, asserting that apic_id_to_cpu_id[256] was written.

Kernel references

• sys/platform/pc64/apic/lapic.c:1212-1217 — lapic_set_cpuid (no bounds check)
• sys/platform/pc64/apic/lapic.c:122-123 — 256-element mapping arrays
• sys/platform/pc64/acpica/acpi_madt.c:330-342 — pass2 callback, no bounds check
• sys/platform/pc64/acpica/acpi_madt.c:413 — probe filter the enumeration phase fails to mirror
• sys/platform/pc64/x86_64/mptable.c:571 — safe pattern (else if (cpu < MAXCPU))

DF-1042 — lapic_set_cpuid missing bounds validation → OOB BSS write via crafted MADT

Verdict

REPRODUCED (boot-time firmware-data OOB write; not userspace-reachable). Fix VALIDATED on a single-fix kernel (#1): the OOB is gone.

Mechanism (confirmed, path:line at every hop)

lapic_set_cpuid(int cpu_id, int apic_id) at sys/platform/pc64/apic/lapic.c:1212-1217 writes its two parameters directly as indices into the 256-element globals with no bounds check:

void lapic_set_cpuid(int cpu_id, int apic_id) {
    CPUID_TO_APICID(cpu_id) = apic_id;   /* cpu_id_to_apic_id[cpu_id]   */
    APICID_TO_CPUID(apic_id) = cpu_id;   /* apic_id_to_cpu_id[apic_id]  */
}

• CPUID_TO_APICID/APICID_TO_CPUID expand to raw array indexing (sys/platform/pc64/apic/lapic.h:37-38).
• The arrays are int[NAPICID], NAPICID = 256 (apicvar.h:41), declared at lapic.c:122-123. Index 256 is out of bounds.

The x2APIC MADT pass2 callback madt_x2apic_pass2_callback (acpi_madt.c:320-346) is the reachable sink:

cpu = arg->cpu; arg->cpu++;                              /* acpi_madt.c:337-338  -- UNcapped   */
...
lapic_set_cpuid(cpu, x2apic_ent->LocalApicId);           /* acpi_madt.c:342     -- u32, unchecked */
CPUID_TO_ACPIID(cpu) = x2apic_ent->Uid;                  /* acpi_madt.c:343     -- also unbounded */

• x2apic_ent->LocalApicId is a UINT32 (ACPI spec) and can be any 32-bit value; it is passed straight through as apic_id. → apic_id-dimension OOB.
• arg->cpu starts at 1 (acpi_madt.c:364) and is incremented for every enabled non-BSP entry with no cpu < MAXCPU check, unlike the mptable path which guards with else if (cpu < MAXCPU) at mptable.c:571. With

  256 enabled entries cpu reaches 256 → cpu-dimension OOB (and the adjacent CPUID_TO_ACPIID(cpu) write to cpu_id_to_acpi_id[NAPICID] (acpi_madt.c:83) is likewise unbounded).

• MAXCPU == SMP_MAXCPU == NAPICID == 256 (sys/cpu/x86_64/include/param.h:71-72).
• The probe phase filters LocalApicId < APICID_MAX (acpi_madt.c:413) and only sets madt_use_x2apic when no legacy LOCAL_APIC entries exist (acpi_madt.c:460-476); pass2 then processes every enabled x2APIC entry regardless of LocalApicId. This probe/enumerate inconsistency is the core defect. The naps cap (lapic.c:1183-1193) runs after iteration, so it does not prevent the OOB writes during iteration.

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

A full call-site audit (grep -rn 'lapic_set_cpuid(' sys/) 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. 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. This is a legitimate but high-bar precondition; it is correctly scoped Medium, not High.

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 (DoS) 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).

Dynamic proof (harness on the real kernel)

Because the path is boot-only, and because QEMU's -acpitable appends a second MADT while the kernel's sdt_search() (acpi_sdt.c:196-214) returns the first matching signature, 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). findings/poc/DF-1042/gen_madt.py is still shipped as the conceptual attacker data (a valid 88-byte MADT with a BSP LocalApicId=0 entry and a malicious LocalApicId=256 entry).

df1042_harness.c is a kld module that calls the real exported lapic_set_cpuid() symbol with the exact argument the crafted MADT forces the pass2 callback to pass — lapic_set_cpuid(1, 256) — and observes the resulting corruption on the live kernel BSS. From nm /boot/kernel/kernel.debug the linker placed the two mapping arrays back-to-back in BSS:

0xffffffff818d9d20  B apic_id_to_cpu_id     (256 ints, 0x400 bytes)
0xffffffff818da120  B cpu_id_to_apic_id     (256 ints, 0x400 bytes)  <-- [256]==0x818da520 == lapic_mem

So apic_id_to_cpu_id[256] (offset +0x400 from 0x818d9d20 = 0x818da120) aliases cpu_id_to_apic_id[0] — the BSP's CPU→APIC mapping. (The finding's specific claim that the small overflow hits lapic_enable/lapic_usable/ x2apic_enable is slightly off: those live in .data at 0x8113e650/654, not in the adjacent BSS. The actual adjacent victims are cpu_id_to_apic_id[0] and, one array further, lapic_mem — the LAPIC MMIO base pointer — which is equally critical.)

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

DF1042: lapic_set_cpuid=0xffffffff80bdd180 cpu_id_to_apic_id=0xffffffff818da120 apic_id_to_cpu_id=0xffffffff818d9d20
DF1042: &apic_id_to_cpu_id[256]=0xffffffff818da120  &cpu_id_to_apic_id[0]=0xffffffff818da120  (same addr => index 256 aliases cpu_id_to_apic_id[0])
DF1042: BEFORE lapic_set_cpuid(1,256): cpu_id_to_apic_id[0]=0 [1]=1 (BSP apic id is 0)
DF1042: AFTER  lapic_set_cpuid(1,256): cpu_id_to_apic_id[0]=1 [1]=256
DF1042: OOB WRITE CONFIRMED -- apic_id_to_cpu_id[256] OOB write clobbered cpu_id_to_apic_id[0]

cpu_id_to_apic_id[0] (the BSP mapping) changed 0 → 1: the out-of-bounds write to apic_id_to_cpu_id[256] landed on it. On a real malicious-MADT boot this corrupts the BSP/AP mappings and (for the cpu-dimension OOB) lapic_mem, producing a boot panic or corrupted LAPIC state.

Fix (fix.diff — validated)

Two complementary changes:

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 both the apic_id-dimension OOB (x2APIC LocalApicId >= 256) and the cpu_id-dimension OOB.

2. Defense-in-depth guards in the MADT pass2 callbacks (acpi_madt.c): skip the entry before both lapic_set_cpuid and the adjacent CPUID_TO_ACPIID(cpu) write when cpu >= MAXCPU (legacy + x2APIC) or x2apic_ent->LocalApicId >= APICID_MAX (x2APIC, mirroring the probe filter at acpi_madt.c:413). This keeps the cpu counter and the unbounded cpu_id_to_acpi_id write safe even if lapic_set_cpuid is ever called from a future caller.

PATCHED kernel (6.5-DEVELOPMENT #1, fix.diff applied)

lapic_set_cpuid: invalid cpu_id 1 apic_id 256, skipping
DF1042: BEFORE lapic_set_cpuid(1,256): cpu_id_to_apic_id[0]=0 [1]=1 (BSP apic id is 0)
DF1042: AFTER  lapic_set_cpuid(1,256): cpu_id_to_apic_id[0]=0 [1]=1
DF1042: no corruption -- apic_id_to_cpu_id[256] OOB write did not reach cpu_id_to_apic_id[0]

cpu_id_to_apic_id[0] is unchanged; the bounds check fired and returned early. Reproduced twice (deterministic). The fix supersedes the finding markdown's proposal (which fixed only lapic.c): the markdown fix is correct and necessary, but insufficient alone because the adjacent CPUID_TO_ACPIID(cpu) write in the same callback is equally unbounded on the cpu dimension; fix.diff closes that too.

Build & kernel

• Single-fix kernel built from /usr/src with the audit commit + findings/poc/DF-1042/fix.diff applied: make -j6 nativekernel KERNCONF=X86_64_GENERIC → NK_DONE rc=0.
• Installed as the bare /boot/kernel/kernel (sha256 bc94555c466f0c9bf478edb64d81d3201638e2341e23f9060f0ce0eaebb4ac7b).
• kern.version: DragonFly 6.5-DEVELOPMENT #1: Tue Jul 14 08:26:18 UTC 2026 (vs the #0 baseline Thu Jul 2 06:02:54 UTC 2026).

PoC changes

• Added df1042_harness.c + Makefile (kld harness driving the real lapic_set_cpuid symbol — the sanctioned primitive-proof 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).