# DF-5351 VERDICT — reproduced (panic + proven OOB write primitive), driver-facing MSI ABI, Low severity

## Bottom line

REPRODUCED on the guest, on a kernel built exactly like production
(X86_64_GENERIC minus `options INVARIANTS`; stock `GENERIC` ships without
INVARIANTS too): `ioapic_abi_msi_alloc_intern()` performs **no runtime
validation** of the driver-supplied `count`. A KLD (the driver-facing ABI,
identical in reach to `PCIB_ALLOC_MSI` → `nexus_alloc_msi` →
`MachIntrABI.msi_alloc`) passing `count=64` gets a clean success return and
**32 kernel words written past the caller's 32-int contract array**
(ioapic_abi.c:1295 `intrs[j] = intr`; the reference caller's array is the
on-stack `int irqs[32]` at sys/bus/pci/pci.c:1952/2072). `count=128` (the
PCI-spec maximum a device may advertise via MMC=7) additionally makes the
loop write/read `ioapic_irqmaps[cpuid][192..255]` — one full row past the
192-entry per-CPU row — and call `msi_setup(intr=192..255)`, whose
`msi_intr[192..255]` OOB read (msi.c:433) feeds garbage "handlers" into
`setidt()` over the IPI gate range: the machine died with RIP
`0x6970695f` (ASCII "_ipi", a rodata string fragment loaded as an
instruction pointer). Fix validated: with runtime count validation both
counts return EINVAL (22), no canary writes, no crash, and legal
allocations (count=1 msix) keep working.

## How it was reproduced (baseline, unfixed production-behaviour kernel)

RUN 1 — safe canary demo (full output in run.log):

    msiabi_probe: calling msi_alloc(count=64, cpu0) (contract max is 32)
    msiabi_probe: msi_alloc rc=0
    msiabi_probe: zone[0..7] = 128 129 130 131 132 133 134 135
    msiabi_probe: 32/96 canary words past zone[31] overwritten (32 expected ...)
    msiabi_probe:   zone[32]=160  <-- OOB write past 32-int contract
    msiabi_probe: msi_release(64) done          <- guest healthy afterwards

`zone` is a 128-int buffer of which only zone[0..31] are inside the ABI
contract; the kernel wrote zone[32..63]. In the real caller this is the
kernel stack. (KASSERT at ioapic_abi.c:1256 would have rejected count=64 —
on an INVARIANTS kernel only.)

RUN 2 — count=128 crasher (full output in panic_row128.txt):

    msiabi_row128: msi_alloc(count=128, cpu5) ...
    msiabi_row128: rc=0
    msiabi_row128: zone[0..3] = 12Stopped at      0x6970695f:  kernel: type 12 trap, code=0
    db>

rc=0 proves the scan accepted a 128-wide "block" spanning
ioapic_irqmaps[5][128..191] plus row [6][0..63] (the next CPU's row — the
alloc ran on cpu ncpus-1 whose successor row is all-zero/UNUSED). The
kprintf of zone[0..3] was cut mid-number because the msi_setup() calls
inside the alloc had already installed OOB-read garbage into the IPI IDT
gates and an IPI fired before the print finished. RIP 0x6970695f = bytes
5f 69 70 69 = "_ipi" — a substring of kernel rodata (e.g. "send_ipiq"),
i.e. a value read from beyond the 192-entry msi_intr[] table used as a
function pointer. Fully consistent with the static analysis of
ioapic_abi.c:1269-1305 + msi.c:431-435.

## Primitive characterization (why panic, not uid0)

The write primitive is: for each j in [0,count): intrs[j] = i + j and
ioapic_irqmaps[cpuid][i+j].{im_type,im_msi_base} = {4|5, i} — linear,
values constrained to small ints and intr numbers. The strongest
consequence (count≥128) is the IDT/IPI-gate smash with semi-controlled
(kernel-data-derived) target RIPs and the row-crossing irqmap corruption.
Triggering requires a driver calling the MSI ABI with a bad count — i.e.
already-privileged code (kldload) or a malicious PCIe device paired with a
driver that forwards the device-reported message count. No unprivileged
entry point exists (verified: no sysctl/ioctl/dev-node surface in this
file; the only untrusted-input path into the file is the boot-time
hw.ioapic.msi_start tunable, already covered by DF-1037). Hence Low
severity / dos impact — but the primitive is real memory corruption past
an attacker-influenced array bound, not a mere assert.

## Fix validation (fix.diff, applied to guest /usr/src, incremental rebuild)

Baseline reproduced (runs 1+2 above) → apply fix.diff (runtime
`count`/powerof2/cpuid checks returning EINVAL/early-return in
msi_alloc_intern/msi_release_intern) → rebuild X86_64_NOINV (#1 08:38:15)
→ reboot → identical PoCs (run_fixed.log):

    msiabi_probe:  msi_alloc rc=22 (EINVAL), "alloc failed, no canary test",
                   SAFE PHASE COMPLETE, msix count=1 round trip still OK
    msiabi_row128: rc=22, SURVIVED — no crash, guest healthy

Bad behavior gone; no regression on legal allocations.

## What I had to fix vs. a naive PoC (poc_changes)

- DFly master's `DECLARE_MODULE(name, data, sub, order)` takes a
  moduledata_t, not a modevent handler (sys/sys/module.h:120-123) — the
  natural FreeBSD-style invocation crashes in module_register (took a
  DDB backtrace over a serial socket to find; guest plumbing, not the
  finding).
- Modules must be built with the in-tree recipe (`SYSDIR?=${.CURDIR}/../..`
  + `.include "${SYSDIR}/conf/kmod.mk"` + `SRCS+= device_if.h bus_if.h`);
  the `make -f kmod.mk KMOD=…` override form produces unloadable .ko on
  this guest.
- The count=128 crasher must run on cpu `ncpus-1` (its successor map row
  is the un-fixup'd zero row), hence `ncpus - 1` in the module.
- The legacy-range scan: on this QEMU guest irqs 19-23 are legacy
  level/low maps on some CPU; the DF-5352 trigger therefore loops msix
  allocations until irq >= 24 (relevant to the sibling finding).

## Kernel references

- sys/platform/pc64/apic/ioapic_abi.c:1256-1257 (KASSERT-only count check)
- sys/platform/pc64/apic/ioapic_abi.c:1269-1305 (scan loop, intrs[j]=intr, msi_setup)
- sys/platform/pc64/apic/ioapic_abi.c:1321-1330 (release count check + intrs[i] read)
- sys/sys/systm.h:94-122 (KASSERT/KKASSERT compiled out without INVARIANTS)
- sys/bus/pci/pci.c:1952,2072 (caller's 32-int stack arrays)
- sys/platform/pc64/x86_64/msi.c:431-435 (msi_setup: msi_intr[intr] + setidt)
- sys/config/GENERIC (no INVARIANTS) vs sys/config/X86_64_GENERIC:56

## 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.