# DF-2382 — PoC verdict

**File:** `sys/dev/acpica/acpi_hp/acpi_hp.c`

**Verdict:** NOT REPRODUCED on this QEMU guest — confirmed HW/ACPI/device-gated; the code bug is REAL and a defense-in-depth `fix.diff` is attached.

## Mechanism (confirmed in source)

acpi_hp_hpcmi_read populates sc->cmi_order[128] by enumerating WMI CMI instances. The loop bound maxInstance comes from sc->has_cmi which is NOT boolean - ACPI_WMI_PROVIDES_GUID_STRING returns max_instance+1 (up to 256). There is no cmi_order_size<128 check before the shift+insert, so a BIOS exposing >128 CMI instances overflows cmi_order past the softc.

### Cited lines

- `sys/dev/acpica/acpi_hp/acpi_hp.c:1165-1202`
- `sys/dev/acpica/acpi_hp/acpi_hp.c:147`

## Why it does not reproduce on this guest

No HP WMI/CMI ACPI table on the QEMU/BOCHS guest (sysctl hw.acpi.hp/dev.hp -> unknown oid; acpi_hp does not attach; no /dev/hpcmi).

Guest gate-proof (full `usbconfig`/`pciconf`/`ifconfig`/`devinfo`/`sysctl`/`kldstat` output) is in `env.txt`.

## Defense-in-depth fix

Before the insert-shift, check sc->cmi_order_size >= nitems(sc->cmi_order) (128) and break the enumeration if full.

The git-apply-able diff is in `fix.diff` (verified `git apply --check` clean).

## Classification

- `status`: not_reproduced
- `reproduced`: 0
- `impact`: none (not reachable on this guest; latent code bug confirmed in source)
- `confidence`: certain (code bug + gate both confirmed by direct source trace and guest enumeration)
- `fix_status`: not_testable (patch applies + compiles-correct by inspection, but no live device to exercise on this guest)