DF-4261 — acpi_pst_attach() leaks the allocated _PCT bus resources on every error path after acpi_pst_alloc_resource()

Impact

Info (hardening / correctness). Boot-time bus-resource leak (I/O port or memory window + permanently bumped cpu_next_rid in the parent cpu softc) when the _PSS/_PPC/_PDL objects of a crafted ACPI table fail validation after _PCT registers were successfully allocated. Requires attacker-controlled ACPI tables (firmware/loader privilege), so no runtime privilege boundary is crossed — but it is a real error-path asymmetry that a maintainer can act on, and resource leaks at failed attach are exactly the class that later turns into use-after-free/range-confusion when drivers are re-probed.

Where (sys/dev/acpica/acpi_cpu_pstate.c)

• :499-504 control register allocated (sc->pst_creg.pr_res, rid bumped at acpi_pst_alloc_resource:1508-1516)
• :511-516 status-register GAS extraction fails -> return error with pst_creg.pr_res still held
• :545-547, :551-554, :570-574, :589-594, :596-603, :605-611 every _PSS validation failure returns with BOTH registers held
• :688-690 (_PPC), :734-736 (_PDL) same

Fix

fix.diff: add acpi_pst_release_resource() (type derived from pr_gas.SpaceId exactly like acpi_bus_alloc_gas, sys/dev/acpica/acpi.c:1261-1270) and route all post-_PCT failures through a failed: label. Not compile-validated (Info-severity, not exercised at runtime).

Verification

Not executed (Info hardening finding; live trigger needs a crafted ACPI SSDT via -acpitable, and the guest's QEMU SSDT exposes no _PSS/_PCT at all — dev.cpu.0 has no freq nodes). Code-path proof is complete in VERDICT.md.

VERDICT — DF-4261

Status: untested (Info-severity hardening finding; not PoC-verified per audit policy for Info findings). Confidence in the code defect: certain.

Code-path proof

acpi_pst_attach() allocates the _PCT control register via acpi_pst_alloc_resource() (sys/dev/acpica/acpi_cpu_pstate.c:500), which on success stores a live struct resource * in sc->pst_creg.pr_res and burns a rid from sc->pst_parent->cpu_next_rid (acpi_cpu_pstate.c:1508-1516). From that point on, every error return leaves the resource(s) allocated:

The device never attaches on these paths, so nothing ever releases pr_res; the rid counter in the parent acpi_cpu_softc is also consumed. Attacker model: whoever controls the ACPI namespace (firmware image, loader-injected DSDT/SSDT) — i.e., already-privileged at boot. Hence Info.

Not runtime-verified: exercising it would require injecting a crafted SSDT (Processor + _PCT with a valid SystemIO GAS + _PSS/_PPC/_PDL that then fail validation) via QEMU -acpitable; the audit guest's firmware exposes no _PSS/_PCT at all (verified live: dev.cpu.0 carries no freq/px nodes, and hw.acpi.cpu.* exposes only C-state knobs), so there is no in-guest surface to observe the leak on without building custom AML, which the policy for Info findings does not warrant.

Fix

fix.diff (authored, not compile-validated — mechanical goto-fail refactor): acpi_pst_release_resource() releases pr_res using the resource type derived from pr_gas.SpaceId (mirroring acpi_bus_alloc_gas, sys/dev/acpica/acpi.c:1261-1270), called from a new failed: label covering all post-_PCT error returns, and directly on the status-register failure path.

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.