DF-2590 — PoC evidence pack

Finding: acpi_panasonic_hkey_event() calls AcpiEvaluateObject for HINF and immediately dereferences res = buf.Pointer without checking status or NULL (sys/dev/acpica/acpi_panasonic/acpi_panasonic.c:403-405). Triggered by an ACPI notify 0x80 (Panasonic Fn hotkey) when the evaluation fails. The late if (buf.Pointer) AcpiOsFree at :420-421 shows the author knew the pointer can be NULL — one check too late.

Rig

Same verbatim-interposition kernel harness as DF-2386 (see that README). The real attach's AcpiInstallNotifyHandler(acpi_panasonic_notify, sc) is captured by the interposer; hw.panasim.cmd=3 dispatches notify 0x80 to the captured real verbatim handler exactly the way ACPICA's deferred notify thread would. hw.panasim.hinf_mode selects the HINF reply (1 = integer happy path, 0 = evaluation failure, buffer untouched).

Build

sh build.sh            # shared with DF-2386

Run

sh run.sh              # happy-path notify, then armed failure -> panic

Expected result (baseline)

• happy path (hinf_mode=1, HINF integer 0x81): full verbatim notify path runs — key 1 decode, brightness action (SSET observed), real acpi_UserNotify fires — no panic;
• armed (hinf_mode=0): injected notify → kernel panic (fatal trap in acpi_panasonic_hkey_event, fault va 0x0), captured in panic.txt.
• fixed build: device_printf "HINF evaluation failed", no panic.

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.