# PoC DF-1480: acpi_pst sysctl leaks uninitialized kernel stack

**Class:** uninitialized kernel stack leak
**Cited site:** `sys/dev/acpica/acpi_cpu_pstate.c:1255-1265, 1271-1281`

## Reproduction status

HW/module gated — **cannot be live-triggered on the audit QEMU guest.**

No on this guest — acpi(4) is in GENERIC but the QEMU guest exposes no _PSS package, so no `hw.acpi.cpu.pst` nodes exist and acpi_pstate_count/start are 0. Trigger requires either ACPI loader tunables (hw.acpi.cpu.pst.ppc/pdl) or a malicious ACPI SSDT to put the driver in a bad start>count state.

The bug is **confirmed at the source level** by tracing the cited path:line in
`sys/dev/acpica/acpi_cpu_pstate.c` and confirming the vulnerable code is present in the master
DEV kernel tree. The `fix.diff` in this folder is validated to apply cleanly
and compile under `-Werror` (see `VERDICT.md`).

## Mechanism

Lines 1255/1271 declare `uint32_t freqs[ACPI_NPSTATE_MAX]; power[ACPI_NPSTATE_MAX];` UNINITIALIZED on stack. Line 1261/1277 `cnt = scount - sstart;` (signed int). When cnt<0 the for-loop is skipped, leaving the array raw. Then `sysctl_handle_opaque(oidp, freqs, cnt*sizeof(freqs[0]), req)` — int * size_t promotes to size_t, so cnt=-1 becomes 0xFFFFFFFF… → uiomove copies a huge amount of uninitialized stack to userspace. Even for sane but wrong cnt, partially-uninitialized tail of the array leaks.

## Realistic impact ceiling

leak (info leak / panic on huge size)

## Fix

Clamp cnt to [0, ACPI_NPSTATE_MAX] before the loop in both freqs_bin and power handlers.

See `fix.diff` for the git-apply-able patch.

## How to validate the fix

```
# 1. Apply fix.diff against the in-guest source:
scp -F dfbsd-qemu/config fix.diff dfbsd:/root/DF-1480.diff
ssh -F dfbsd-qemu/config dfbsd 'cd /usr/src && patch -p1 < /root/DF-1480.diff'

# 2. Rebuild the affected module (preferred) or a single-fix kernel:
ssh -F dfbsd-qemu/config dfbsd 'cd /usr/src/sys/sys/dev/acpica && make'

# 3. The compile must succeed with -Werror (it does — see build.log).
```