DF-3795 — acpi_parse_prw() copies the wrong _PRW elements as power resources

• File: sys/dev/acpica/acpi.c (pass 2)
• Lines: 2962–2970 (off-by-two at 2969–2970)
• Class: CWE-682 (incorrect computation) / incorrect index
• Severity: Low (functional/availability, firmware-dependent) · Confidence: certain

What

Per ACPI spec (and the code's own comment), _PRW packages are:

Package { <gpe>, <lowest_wake_sstate>, <power-resource ref>, ... }
          elem0    elem1                elem2 .. elemN

acpi_parse_prw() computes power_count = Package.Count - 2 — the number of power-resource references — but then copies elements 0 .. count-1 instead of 2 .. N:

    /* Elements 2 to N of the _PRW object are power resources. */
    power_count = res->Package.Count - 2;
    ...
    for (i = 0; i < power_count; i++)
    prw->power_res[i] = res->Package.Elements[i];   /* should be [i + 2] */

Consequences in the consumer (acpi_powerres.c:552-556 acpi_pwr_wake_enable() → acpi_pwr_reference_resource() → acpi_GetReference(), acpi_package.c:132):

• Elements 0 and 1 are an INTEGER (GPE bit) or a PACKAGE (GPE handle+bit) and an INTEGER (lowest wake state). acpi_GetReference() type-checks and returns NULL for both ⇒ dropped (no memory-safety impact).
• With exactly one power resource (Count == 3) the real reference at element 2 is never copied; with more, a shifted prefix (2..Count-3) is used. Net effect: wake power resources are not powered on at sleep (acpi_wake_sleep_prep, acpi.c:2752-2754) nor cleaned up on wake (acpi.c:2789-2790), so devices whose wake depends on those rails cannot wake the machine (availability), and stale/extra references may keep rails on after resume.

This bug is inherited from FreeBSD (verified identical in freebsd-src/main sys/dev/acpica/acpi.c ~line 4117), so it is a long-standing MI defect, not a DFly-only divergence — but it is still a defect in this tree.

Guest testability

The QEMU guest's DSDT contains no _PRW objects at all (acpidump -b -n DSDT; iasl -d; grep -c _PRW → 0), so the mis-parse cannot be triggered on this guest; the verdict is code-certain but runtime-not_reproduced. Hardware with wake-capable devices whose _PRW lists power resources (Count > 2 — common for PCIe WOL, wake-on-lid, Suns/USB on laptops) is affected.

Fix

See fix.diff: prw->power_res[i] = res->Package.Elements[i + 2];

DF-3795 VERDICT

Status: not_reproduced on this guest — code-certain by trace; no _PRW in guest firmware

Guest: QEMU-emulated DragonFly 6.5-DEVELOPMENT (X86_64_GENERIC).

Why not reproduced at runtime

acpidump -b -n DSDT && iasl -d on the guest: its DSDT contains zero _PRW objects (grep -c _PRW dsdt.dsl → 0). The mis-parse only fires for _PRW packages with Count > 2 (i.e. wake-capable devices listing power resources). Exercising it requires different firmware, not different userspace — a guest-runtime proof is impossible on this DSDT, so the honest status is not_reproduced rather than a forced demonstration.

Why the code defect is certain

• The function's own comment (acpi.c:2962) states elements 2 to N are the power resources; the loop at acpi.c:2969-2970 copies Elements[i] for i in [0, power_count), i.e. elements 0 to Count-3.
• ACPI spec semantics of _PRW: elem0 = GPE indicator (INTEGER or PACKAGE), elem1 = lowest wake sleep state, elem2.. = power-resource references.
• Consumer path is type-safe — acpi_pwr_reference_resource() (acpi_powerres.c:582) → acpi_GetReference() (acpi_package.c:132-160) returns NULL for INTEGER/PACKAGE elements — so elements 0/1 are dropped, and with Count==3 the single genuine power resource at element 2 is never referenced. Effect: acpi_wake_sleep_prep (acpi.c:2752-2754) never turns on the device's wake power rails; acpi_wake_run_prep (acpi.c:2789-2790) never cleans them. Availability/functional impact on wake-capable hardware; no memory-safety impact.
• Cross-check: FreeBSD main has the identical line (freebsd-src/sys/dev/acpica/acpi.c ~4117: Elements[i]) — inherited MI bug, not a DFly divergence.

Fix validation

fix.diff (Elements[i + 2]) was compiled into the patched test kernel together with the DF-3793/DF-3794 fixes (one-line change; the affected branch is unreachable on this guest's firmware), so runtime behavioral validation of this specific change is honestly not_testable here; the index arithmetic is self-evident against the comment and the consumer.

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.