# DF-2590 — PoC verdict

**File:** `sys/dev/acpica/acpi_panasonic/acpi_panasonic.c` (:403-405)

**Verdict:** **REPRODUCED** — `acpi_panasonic_hkey_event()` discards
the `AcpiEvaluateObject` return for HINF and dereferences
`res = buf.Pointer` (NULL on any evaluation failure) at :405. An ACPI
notify `0x80` (Fn hotkey on Panasonic hardware) while HINF fails
panics the kernel at exactly that load. Same NULL-Type class as
DF-2386 but notify-reachable instead of sysctl-reachable; the late
`if (buf.Pointer) AcpiOsFree(buf.Pointer)` at :420-421 shows the
author knew the pointer can be NULL — the check is simply one
statement too late. Fixed build survives the identical injection
(A/B validated).

## Line-accurate confirmation

1. `acpi_panasonic.c:401-402` — `buf.Length = ACPI_ALLOCATE_BUFFER;
   buf.Pointer = NULL;`
2. `:403` — `AcpiEvaluateObject(h, "HINF", NULL, &buf);` — status
   discarded.
3. ACPICA failure contract (nsxfeval.c:525-631, see DF-2386 VERDICT):
   `Pointer` stays NULL on every failure.
4. `:404-405` — `res = (ACPI_OBJECT *)buf.Pointer;
   if (res->Type != ACPI_TYPE_INTEGER)` — NULL deref.
5. Reach: `acpi_panasonic_notify` case `0x80` (:486-492) takes the
   serial and calls `acpi_panasonic_hkey_event` (:488) — on hardware
   this is the Fn-hotkey notify; no privilege involved in the *fault
   context*, but the trigger requires a firmware event.

## Mechanical verification

Same rig as DF-2386 (see that VERDICT). The real attach registered
the verbatim `acpi_panasonic_notify` through the interposed
`AcpiInstallNotifyHandler` (captured handler+ctx). `hw.panasim.cmd=3`
dispatches notify `0x80` to the captured **real** handler from a
kthread, mirroring ACPICA deferred notify dispatch.

Baseline (kernel #4):

- **happy path** (`hinf_mode=1`, HINF integer `0x81`): notify →
  `acpi_panasonic_hkey_event` decodes key, `acpi_UserNotify` fired
  (`notify_seen=1`), handler returned, no panic — the notify plumbing
  is proven working first;
- **armed** (`hinf_mode=0`: HINF evaluation fails, buffer untouched):
  injected notify → **kernel panic**, 4/4 deterministic:

```
Stopped at      acpi_panasonic_notify+0x9f:     cmpl    $0x1,(%rdi)
db>
```

`cmpl $0x1,(%rdi)` is `res->Type != ACPI_TYPE_INTEGER`
(`ACPI_TYPE_INTEGER == 1`) with `%rdi = res = NULL` — the compiler
inlined `hkey_event` into `acpi_panasonic_notify`, hence the symbol;
the immediate `0x1` fingerprints :405 exactly the way `0x4`
(ACPI_TYPE_PACKAGE) fingerprinted :279 in DF-2386. `panic.txt`
carries the serial capture (`login: PANASIM: worker: exec cmd=3` /
`PStopped at ...`); the full trap block is lost to a console artifact
specific to the notify-thread context (ALL console output from that
thread is dropped — see notes), so the DDB stop line plus the
happy-path contrast plus the identical DF-2386 trap block constitute
the evidence set. The ssh session dies at trigger time
("Connection closed by remote host", run.2.log).

## Reachability / privesc assessment (honest)

- Hardware precondition: Panasonic `MAT0019` firmware; trigger is an
  ACPI notify (physical Fn key press) coinciding with an HINF
  evaluation failure (memory pressure / firmware anomaly). The
  attacker model is "person with the keyboard + a failing eval" or
  hostile/crafted firmware — matching the Low / AC:H / UI:R scoring.
- Impact: NULL-deref **panic** in notify dispatch. No write
  primitive; not a privesc.

## Fix validation (A/B)

Fixed kernel (#6): happy path unchanged (`notify_seen=1`); armed
injection → rig ring records
`inject: dispatching notify 0x80 ... → eval HINF -> AE_NO_MEMORY →
inject: handler returned` — handler returns cleanly (baseline
panicked at exactly this point), guest stays up (`run_fixed.log`).

## Console-output note

During verification we observed that all console/msgbuf output
originating from the injected-notify kthread is silently dropped
(both kprintf lines and the trap block; only DDB own prints survive).
This is a rig/console artifact of thread context, not driver
behavior; it is why the 2590 trap block is shorter than DF-2386's.

## Artifacts

`run.log`/`run.2.log` (baseline attempts), `panic.txt` (serial with
the DDB stop), `run_fixed.log`, rig sources, `build.sh`/`run.sh`,
`build.log`, `fix.diff`, `env.txt`.

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