DF-4451 — heap OOB write in link_add_crs (and link_add_prs / srs_from_crs / route_irqs) from temporal divergence of _CRS/_PRS evaluations

File: sys/dev/acpica/acpi_pci_link.c (pass 2)

What the bug is

acpi_pci_link_attach() sizes the pl_links[] heap array from a counting walk of the link device's _CRS (acpi_pci_link.c:465), then runs populating walks (link_add_crs at :504, link_add_prs at :522) that index pl_links[req->link_index] with no runtime bound check — only a KASSERT (:235) / KKASSERT (:767, :896), which are no-ops on INVARIANTS-free production kernels (sys/sys/systm.h:117-119).

If the _CRS (or _PRS) method returns a different resource count on a later evaluation than on the counting evaluation, the populate walks write past the end of pl_links. The ACPI specification does not require methods to be pure: side effects and stateful returns are legal AML, and on this system _CRS of a PNP0C0F link device is evaluated at least three times per boot by three independent kernel consumers:

1. sys/dev/acpica/acpi.c:1908 — acpi_parse_resources() during ACPI child enumeration (evaluates _CRS via acpi_resource.c),
2. sys/dev/acpica/acpi_pci_link.c:465 — counting walk,
3. sys/dev/acpica/acpi_pci_link.c:504 — link_add_crs walk,
4. (later, at route/resume time) sys/dev/acpica/acpi_pci_link.c:727 — acpi_pci_link_srs_from_crs() re-evaluates _CRS and walks it with the same unbounded link/i cursor (:766-789 read side, :893-913 write side link->l_routed = TRUE).

This is distinct from the known pass-1 findings: DF-2389 is a static count mismatch between two different buffers (_PRS vs _CRS), DF-2390 is the DPF structural inconsistency inside one buffer. Here a single, well-formed, DPF-free buffer whose method simply returns different (equally valid) content on successive evaluations drives the same out-of-bounds writes.

Threat model

Firmware-supplied ACPI (crafted SSDT/DSDT in a bootable VM image — the same bar as DF-2389/2390), or a buggy BIOS with a stateful _CRS. No unprivileged runtime trigger is needed: the write fires during boot device attachment (device_doattach → acpi_pci_link_attach).

Reproduction on the audit guest (done)

• Inject an SSDT defining \_SB.LNKX (PNP0C0F) whose _CRS returns 1 IRQ descriptor on the first two evaluations (acpi.c:1908 pre-parse + counting walk) and 128 IRQ descriptors afterwards (the link_add_crs walk): ssdt_lnkx_v2.asl (ASL), ssdt_lnkx_v2.aml (compiled with the guest's /usr/sbin/iasl).
• Boot the guest with the table appended: QEMU_EXTRA="-acptable file=ssdt_lnkx.aml" dfbsd-qemu/vm.sh up (vm.sh passes $QEMU_EXTRA through to qemu-system-x86_64).

Result on stock GENERIC (INVARIANTS kernel): panic — panic.txt

panic: link_add_crs: array boundary violation
link_add_crs() at link_add_crs+0x18a
AcpiWalkResourceBuffer() at AcpiWalkResourceBuffer+0x60
AcpiWalkResources() at AcpiWalkResources+0x9f
acpi_pci_link_attach() at acpi_pci_link_attach+0x3d1
device_doattach() at device_doattach+0x3af
Debugger("panic")

The kernel's own assertion catches link_index >= pl_num_links at acpi_pci_link.c:235 — proving the overrun is reached.

Result on production-style kernel (INVARIANTS removed): the write proceeds

X86_64_GENERIC minus options INVARIANTS (config NOINV4451, see build-noinv.log) — with the asserts compiled out (sys/sys/systm.h:117) link_add_crs writes 128 struct link entries (~13 KB) into a sizeof(struct link) (104-byte) allocation: run-noinv-*.log.

Files

• ssdt_lnkx_v1.asl / ssdt_lnkx_v2.asl — SSDT sources (v1 = count walk divergence attempt that revealed the acpi.c:1908 pre-evaluation; v2 = the firing trigger)
• ssdt_lnkx_v2.aml — compiled SSDT (iasl 20251212, guest /usr/sbin/iasl)
• build.sh — compile the ASL on the guest, fetch the AML back
• run.sh — boot the guest with the table injected
• panic-inv-assert-boot.log — full serial log, INVARIANTS-kernel panic boot
• panic.txt — decisive excerpt
• verbose-benign-boot.log — control boot (threshold not yet reached): shows pci_link5 happily attaching 128 links when both walks see the same buffer
• run-noinv-boot.log — no-INVARIANTS kernel, same SSDT (raw OOB write)
• fix.diff — bounds guards for all four unbounded cursor walks
• fix-validation.log — patched no-INVARIANTS kernel, same SSDT: no panic

DF-4451 — VERDICT

Status: reproduced (boot-time kernel memory-safety violation, guest-verified) Impact: heap OOB write on production (INVARIANTS-free) kernels; boot panic on stock GENERIC. Crafted-ACPI precondition (same threat bar as DF-2389/2390).

What was run

1. Control boot (no SSDT): stock kernel from the with-src snapshot, DragonFly 6.5-DEVELOPMENT #0 Thu Jul 2 06:02:54 UTC 2026 (X86_64_GENERIC), boots clean; 5 pci_link devices attach (pci_link0..4 = LNKA..LNKD, LNKS).
2. Trigger build: ssdt_lnkx_v2.asl compiled with the guest's base /usr/sbin/iasl (version 20251212) → ssdt_lnkx.aml (666 bytes). Injected with QEMU_EXTRA="-acpitable file=ssdt_lnkx.aml" ./vm.sh up (vm.sh passes $QEMU_EXTRA through to qemu-system-x86_64; two-line infrastructure hook added to vm.sh, default-empty).
3. Trigger boot, stock GENERIC kernel (INVARIANTS on): the ACPI bus pre-parses _CRS (acpi.c:1908 → eval #1, returns BUF1), the counting walk gets eval #2 (BUF1 → pl_num_links = 1, pl_links = kmalloc of ONE 104-byte struct link), then link_add_crs gets eval #3 which returns BUF2 (128 IRQ descriptors) → walks 128 links into the 1-element array. At link_index = 1 the kernel panics at its own boundary assertion:

panic: link_add_crs: array boundary violation link_add_crs() at link_add_crs+0x18a AcpiWalkResourceBuffer() at AcpiWalkResourceBuffer+0x60 AcpiWalkResources() at AcpiWalkResources+0x9f acpi_pci_link_attach() at acpi_pci_link_attach+0x3d1 device_doattach() at device_doattach+0x3af

(panic.txt, full serial log panic-inv-assert-boot.log.) This proves the overrun is reached at exactly sys/dev/acpica/acpi_pci_link.c:235-237.

4. Calibration boot (ssdt_lnkx_v1.asl, threshold 1): both walks saw the same BUF2 → 128 in-bounds links, no panic; the verbose dump (verbose-benign-boot.log) shows pci_link5 with links 0..127 — direct evidence that (a) the driver consumes stateful _CRS content verbatim and (b) _CRS of a link device is evaluated ≥3 times per boot by independent consumers (acpi.c:1908, acpi_pci_link.c:465, acpi_pci_link.c:504).

5. Production-style kernel (INVARIANTS removed — config NOINV4451): X86_64_GENERIC minus options INVARIANTS, built with make nativekernel KERNCONF=NOINV4451. With the same SSDT the KASSERT/KKASSERT family compiles to no-ops (sys/sys/systm.h:117-119), so link_add_crs performs the writes: * v3 SSDT (8192 extra descriptors ≈ 850 KB overwrite walk): the machine hard-resets — no panic, no trap, no db> (the overwrite destroyed state the trap machinery itself needs) — and because the SSDT is injected at every boot it crash-loops: 16 reset cycles captured in run-noinv-boot.log. * v2 SSDT (128 extra descriptors ≈ 13 KB overwrite): the system boots and runs normally — the corruption is completely silent (run-noinv-128-stealth-boot.log, system up, uptime 42 s at inspection). Nothing in any log indicates 13 KB of kernel heap was just overwritten.

Primitive characterization

• What: contiguous linear heap overwrite, stride sizeof(struct link) (104 bytes), 9 controlled-ish bytes per stride (res_index = 1,2,3…, crs_type = 3 or 15 (IRQ/EXTIRQ descriptor type), l_irq = first IRQ number in the descriptor mask or 255).
• Where: immediately past a kmalloc(n·104, M_PCI_LINK, M_WAITOK|M_ZERO) allocation in the DF kernel heap.
• How far: fully attacker-chosen — the crafted _CRS decides the number of IRQ descriptors (hundreds to tens of thousands; AML buffer of a few KB is enough for megabytes of overwrite).
• Boot-time, pre-authentication (during device_doattach of the link device).

Turning this into uid=0 would additionally require controlling the heap layout at that early boot stage (grooming which objects sit after pl_links) and useful field values; the per-stride controlled bytes are limited, and the write happens once at boot before userland exists, so weaponization is nontrivial. The vulnerability class (heap OOB write from firmware data) and its reliable DoS/corruption impact are proven; privesc weaponization left unclaimed. On INVARIANTS kernels (stock GENERIC as shipped) the same input is a deterministic boot panic.

False-positive check

Not a false positive: the stock kernel's own KASSERT text fired at the exact cited line with the crafted table loaded (panic.txt), and the count/add divergence is by construction (stateful _CRS, _PRS deliberately benign at 1 descriptor so the KNOWN DF-2389 path — _PRS count > _CRS count — was NOT the trigger; no DPF descriptors exist in either buffer, so DF-2390's mechanism was not involved either).

Fix validation

fix.diff adds real bounds guards to the four unbounded cursor walks (link_add_crs, link_add_prs, acpi_pci_link_srs_from_crs, acpi_pci_link_route_irqs); the same diff also bounds the DF-4452 reads in acpi_pci_link_choose_irq. Applied to the guest's /usr/src copy, kernel NOINV4451 rebuilt, same SSDT re-run: see fix-validation.log + fix_run.log / fix_build.log.

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.