# DF-4426 VERDICT — UINT8 instance wraparound → infinite loop under `hp` lock

## Reproduced?
**On-guest kernel reproduction: no** — the audit guest (QEMU/SeaBIOS, no HP
BIOS) has no PNP0C14 ACPI node, so `acpi_wmi` never attaches
(`env.txt`: no `/dev/wmistat*`, no `hw.acpi.wmi` sysctl), and `acpi_hp`
consequently never creates `/dev/hpcmi` (`env.txt`: no `/dev/hpcmi`, no
`hw.acpi.hp` sysctl oid). The defect requires a physical HP WMI BIOS whose
CMI GUID advertises `max_instance == 254`.

**Logic-level reproduction: YES, on the DragonFly guest itself** — the exact
loop control flow from acpi_hp.c:1164-1204 was extracted verbatim into
`wrap_harness.c` (only the WMI layer stubbed; `UINT8` = `unsigned char`
identical on DFly x86-64), compiled with DragonFly cc 8.3 **on the guest**,
and run (`run.log`):

- error at instance 0 → **300,000 body executions, 0 inserts** — a pure
  infinite loop with zero memory writes. In-kernel this pins the calling
  thread inside `dev_read` forever while it holds
  `lockmgr(&hp_serial, LK_EXCLUSIVE|LK_RETRY)` (acpi_hp.c:1157,
  acpivar.h:170) — every later `hw.acpi.hp.*` sysctl op and every
  `/dev/hpcmi` open blocks forever. Unprivileged local DoS (device is 0644,
  acpi_hp.c:523-524).
- error at instance 5 → **unbounded restart**: cmi_order_size reached
  250,000 in the capped demo — in-kernel this drives `cmi_order[128]` OOB
  writes far beyond what DF-2382 describes (which covers >128 *instances*;
  here a *single* broken instance at k causes infinite re-appending of k
  entries per wrap).
- no error → normal 255-iteration termination (control run).

## Root cause (path:line)
- `sys/dev/acpica/acpi_hp/acpi_hp.c:1172` — `for (instance = 0; instance <
  maxInstance; ++instance)` with `UINT8 instance` (declared :1145).
- `sys/dev/acpica/acpi_hp/acpi_hp.c:1178` — `instance = maxInstance;` as the
  error-break idiom; with `maxInstance == 255`, `++instance` wraps to 0 and
  the loop restarts (`UINT8` arithmetic).
- `maxInstance == 255` requires `sc->has_cmi == 255` (WMI GUID
  `max_instance == 254`, returned as `max_instance+1` by
  acpi_wmi.c:344) **and** `ACPI_HP_CMI_DETAIL_SHOW_MAX_INSTANCE` set in
  `hw.acpi.hp.cmi_detail` (sysctl root-writable only —
  kern_sysctl.c:1446 `SYSCAP_NOSYSCTL_WR` check), which skips the
  `maxInstance--` at acpi_hp.c:1168.

## Why the guest can't show the kernel manifestation
No WMI firmware. Injecting a crafted PNP0C14 SSDT into the QEMU firmware is
out of scope for a Low-severity finding; the loop logic itself is fully
characterized and the lock-held-forever consequence is structural (the whole
enumeration runs between `ACPI_SERIAL_BEGIN(hp)`/:1157 and
`ACPI_SERIAL_END(hp)`/:1229).

## Exploit chain
(none — denial of service only: stuck kernel thread + permanently held
global `hp` sx/lockmgr lock; repeatable by any user once the sysctl
precondition is set, e.g. `sysctl hw.acpi.hp.cmi_detail=8` then
`cat /dev/hpcmi` on a matching BIOS.)

## Fix
`fix.diff` (dry-run verified): replace the `instance = maxInstance` idiom
with a `stop` flag + `break`. One-line semantic fix; keeps the loop variable
wrap-proof.

## Fix validation
not_testable — no HP WMI hardware on the guest; the fix is a control-flow
change whose logic effect is directly visible in the harness (with the fix
applied to the harness loop, all three runs terminate).

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