# DF-4242 — VERDICT

**REPRODUCED** (deterministic kernel panic from device-fed registers; fix validated on
a rebuilt kernel — no panic, drain-and-continue).

## What was proven

The trigger is entirely device-fed and needs nothing else: a status packet with an
in-range `ccb_busaddr` and EOC=1, plus register values `HA_RSTATUS & HA_SERROR` and
'DPTH' at offsets 2..5. Dispatching the **production `dpt_intr`** (0xffffffff80439670 in
the shipped X86_64_GENERIC image) over the rig's virtual register file produced, on the
serial console:

```
dpt9: HBA rebooted.
      All transactions should be resubmitted
dpt9: >>---->>  This is incomplete, fix me....  <<----<<panic: DPT Rebooted
cpuid = 2
dpt_intr() at dpt_intr+0x2c2 0xffffffff80439932
```

The backtrace shows the panic executing inside the production handler itself. The panic
fires at dpt_scsi.c:1566, *before* `ccb = dccb->ccb` (line 1571) — no in-flight I/O is
required, the CCB is never dereferenced: **the register signature alone is lethal.**

A controller that merely reboots mid-I/O (firmware crash, power glitch, PCI reset)
presents exactly this signature; a hostile device trivially does. The kernel — the whole
machine — goes down: availability impact with zero privileges beyond being the HBA on
the bus (or its virtualization/passthrough equivalent).

## Fix validation (fix.diff applied, kernel rebuilt + rebooted)

The rig re-ran the identical trigger against an **ACTIVE** in-flight CCB (queued through
production `dpt_action`), so the packet passes the DF-4241 `DCCB_ACTIVE` guard and
reaches the reboot branch itself (`fix_validation.log`):

```
dpt9: HBA rebooted.
      All transactions should be resubmitted
dpt9: >>---->>  This is incomplete, fix me....  <<----<<Encountered bogus status packet
[dptrig] PANIC: dpt_intr RETURNED (unexpected!)
```

- no panic: the fixed branch drains the interrupt (status read) and continues the
  completion loop; the loop then exits cleanly on the bogus next packet;
- the ioctl returned to userland (`PANIC_RC=0`), guest stayed up (uptime verified);
- in-flight commands are recoverable through the existing `dpttimeout`/CAM timeout path,
  which is the fix's intended recovery mechanism.

## Caveats

- The ctl prints "dpt_intr RETURNED (unexpected!)" — that message text predates the fix;
  on the patched kernel the return is the EXPECTED outcome (no panic).
- The rig invoked `dpt_intr` from an ioctl thread; the panic path is register- and
  softc-driven only, so hardirq context is immaterial here.

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