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.