DF-4245 — dpt_get_conf() ready-wait spins forever (with interrupts disabled) on a hostile HBA status shape

Inside crit_enter() (interrupts disabled), dpt_get_conf() waits for the controller to become ready (dpt_scsi.c:505-520). The loop has NO iteration bound and NO timeout: it exits only on (a) one of three exact status-byte values AND controller-not-busy, or (b) registers 0..2 spelling 'DPT' (dpt_raid_busy). dpt_wait() itself gives up after ~1s but its failure merely keeps the outer loop spinning. A controller that parks its status register on any other value (or stays busy forever) hangs the kernel in a hard MMIO-read spin at probe/attach — no timer, no watchdog break-out at that point in boot. Same hostile-input-shape family as DF-4042/4098, hang flavor.

DF-4245 verdict — UNTESTED (hardware-gated); missing loop bound certain from source

Reproduced?

No — requires a DPT controller reporting a stuck status byte; guest has no DPT hardware (env.txt).

Certainty

dpt_scsi.c:505-520: the while condition is (status not in 3 exact values) || (dpt_wait(HA_SBUSY,0) != 0). dpt_wait is bounded (20000*50us, dpt_scsi.c:198-212) but only its RESULT feeds the outer loop, which has no iteration cap and no DELAY; the sole early-exits are the 3 good statuses, or 'DPT' at regs 0..2 (dpt_raid_busy, dpt_scsi.c:171-180). All inputs device-fed; loop runs under crit_enter() (dpt_scsi.c:498). Consequence: boot-time or devd-time hard hang from a faulty/hostile card; availability only. Severity Low (hardware-gated, probe-time).

Fix validation

Not possible without hardware; fix.diff bounds the loop (~60s of dpt_wait passes) and returns failure like the existing RSUS path.

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.