# VERDICT — DF-4694

**Status: inconclusive (hardware-gated) · code-path proven · expected impact: kernel panic (INVARIANTS KKASSERT) or spurious abort of unrelated in-flight I/O**

## Reproduced?

No — no sili(4) HBA / no PM emulation on the audit guest (env.txt). The
trigger runs `camcontrol reset` (XPT_RESET_DEV) 24+ times against the buses
that exist (ata0/ata1 under nata) — all benign (run.log); the defective
`sili_pm_softreset()` is unreachable here. Code-path proof below.

## Why the defect is real (trace)

1. `sili_pm_softreset()` polls its softreset FIS with `sili_quick_timeout`
   and holds the err_ccb: sili_pm.c:445-450 —
   `if (sili_poll(ccb, timeout, sili_quick_timeout) != ATA_S_COMPLETE)`.
   The comment says quick_timeout is used *because* the err_ccb is held.
2. `sili_quick_timeout()`'s ONCHIP branch *asserts sole activity*:
   `KKASSERT((ap->ap_active & ~ap->ap_expired) == (1 << ccb->ccb_slot));`
   — sili.c:2536-2544. The assert encodes the contract "nothing else on the
   chip"; on INVARIANTS kernels (X86_64_GENERIC:56, confirmed on the guest)
   a violation is an immediate panic.
3. Callers of `sili_pm_softreset()` do **not** guarantee that contract:
   - XPT_RESET_DEV: sili_cam.c:904-915 takes `sili_os_lock_port(ap)` only —
     no drain of other PM targets' commands — then
     `sili_port_reset(ap, atx, 0)` → sili.c:744-745 → `sili_pm_softreset()`.
   - Port-thread state machine: sili.c:632 (`NEED_SOFT_RESET` step) — the
     preceding hardreset drained, but completions that arrived meanwhile can
     have queued/issued followers before this step runs.
   Contrast: `sili_pm_hardreset()` explicitly calls `sili_exclusive_access()`
   first (sili_pm.c:272) — the softreset path has no equivalent.
4. Trigger: with ≥1 other PM-target command on-chip and the softreset FIS
   timing out (1000 ms for target 15 / 8000 ms otherwise, sili_pm.c:445 —
   easily exceeded behind a PM when the target is hung), the KKASSERT fires
   → panic. On non-INVARIANTS builds the code proceeds to clear only its own
   `ap_active` bit and calls `sili_port_reinit()` (sili.c:2540-2543), which
   force-completes the *other* still-on-chip commands as ATA_S_TIMEOUT
   (sili.c:403-411) — spurious CAM aborts of unrelated I/O and a port reinit
   storm.

The trigger program drives exactly this entry point (`camcontrol reset` =
XPT_RESET_DEV) with a concurrent dd saturation stream; on PM hardware with a
hung target this is the deterministic panic path.

## Impact ceiling

Kernel panic from an unprivileged-ish trigger (any local user can issue
`camcontrol reset` on a device node they can open, or the kernel reaches the
same path from error recovery); requires PM hardware and a timed timeout.
Severity Medium.

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