# DF-2386 — PoC evidence pack

**Finding:** Unchecked `AcpiEvaluateObject` return in `acpi_panasonic_sinf()`
(`sys/dev/acpica/acpi_panasonic/acpi_panasonic.c:277-279`) — NULL-pointer
dereference panic reachable from an unprivileged local user via the
`CTLFLAG_ANYBODY` sysctl `hw.acpi.panasonic.lcd_brightness`.

## Rig

Verbatim-interposition kernel harness (same shape as the acpi_hp rig,
DF-2383/DF-2384):

- `acpi_panasonic.c` compiled **byte-identical** into a custom
  INVARIANTS kernel (`PANHARNESS` = `X86_64_GENERIC` + `device panasim`;
  sha256-gated by `build.sh`:
  `23e49741027f53dcedd05423f7c5eacd1be0dada1c46277dde0be6694b8d0912`).
- `pana_shim.c` (build glue only) `#define`-renames the driver's ACPI
  externals to `panasim_*`; everything else — newbus probe/attach, the
  sysctl framework, `ACPI_SERIAL_*` locking, `device_printf` — runs real.
- `panasim.c` fabricates the firmware side: the fake
  `acpi_panasonic` child is added to the REAL `acpi0`, the real attach
  creates the real `hw.acpi.panasonic.*` sysctls, and
  `panasim_AcpiEvaluateObject` replies for SINF/HINF/SSET with
  runtime-selectable behavior (including *failure with the buffer left
  exactly as ACPICA leaves it* — `nsxfeval.c:536-600` failure contract:
  `Pointer` stays NULL).

## Build

```
sh build.sh            # push rig + build/install PANHARNESS + reboot (baseline)
sh build.sh fixed      # additionally apply fix.diff to the driver, rebuild
```

## Run

```
sh run.sh              # baseline: expects panic in acpi_panasonic_sinf
sh run.sh fixed        # fixed: expects -1 returned, no panic
```

Baseline sequence: create fake device → unprivileged (maxx) sanity read
of `hw.acpi.panasonic.lcd_brightness` (sane SINF) → root arms
`hw.panasim.sinf_mode=0` (SINF evaluation fails like
`AE_NO_MEMORY`) → **maxx reads the sysctl again → kernel panic** (fatal
trap, `acpi_panasonic_sinf`, fault va 0x0). `panic.txt` carries the
serial-console capture.

## Expected result (baseline)

`Fatal trap 12: page fault while in kernel mode` at
`acpi_panasonic_sinf+…` with `fault virtual address = 0x0`, triggered by
uid 1000's `sysctl` process. Fixed build: the same read returns `-1`,
guest stays up.

Note on reachability: the unprivileged sysctl read is real; the *failure
of the SINF evaluation* at that instant is the firmware/AML side — on
hardware it is caused by e.g. `AE_NO_MEMORY` under memory pressure or a
firmware anomaly. The rig deterministically produces exactly that
failure mode at the exact API boundary the driver consumes.