# DF-3728 VERDICT

## Finding
`ciss_notify_complete()` (`sys/dev/raid/ciss/ciss.c:3598-3663`) has three
exit paths for the completed notify request:

1. **fatal error** (ciss.c:3619-3627):
   `ciss_release_request(cr); sc->ciss_flags &= ~CISS_FLAG_NOTIFY_OK; return;`
   — **`sc->ciss_periodic_notify` is NOT cleared** → dangling pointer to a
   request that is now on the free queue.
2. notifier-aborted (ciss.c:3642-3649): releases AND clears (3648).
3. event queued (ciss.c:3650-3656): clears (3653).

The consumer, `ciss_notify_event()` (ciss.c:3517-3595), starts with
`cr = sc->ciss_periodic_notify;` (ciss.c:3526) and only allocates a fresh
request `if (cr == NULL)` (ciss.c:3529). After a fatal notify status,
`CISS_FLAG_NOTIFY_OK` is clear, so the next `ciss_periodic()` tick
(ciss.c:3427-3430, ≤10 s later) calls `ciss_notify_event()`, which follows
the stale pointer — a request that has been back on `ciss_free` and can have
been **handed to any other submitter** (`ciss_get_request`, ciss.c:2409).

## Consequence chain (all steps mirrored in the harness)
1. `ciss_get_request` re-initializes the slot (ciss.c:2412-2416) and a CAM
   I/O owns it: `cr_data = csio->data_ptr`, `cr_complete = ciss_cam_complete`
   (ciss.c:3078-3081), posted to the adapter.
2. The stale notify path reuses it: `cr->cr_data != NULL` so the 512-byte
   buffer allocation is skipped (ciss.c:3544-3547 — reads the NEW owner's
   data pointer), `ciss_preen_command` (ciss.c:3550) rewrites the header /
   error-info pointer, the notify CDB overwrites the CAM CDB (ciss.c:3554+),
   and `ciss_start` (ciss.c:3579) **posts the same tag a second time**.
3. The adapter completes each post; `ciss_complete` (ciss.c:2164-2204)
   processes both completions: the second one hits
   `"completing non-busy request"` (ciss.c:2169-2170) and then invokes the
   CAM callback again → `ciss_cam_complete` → `xpt_done((union ccb *)csio)`
   (ciss.c:3286) **twice for one CCB** → CAM-side use-after-free, plus
   `ciss_release_request` twice → the same request linked twice on
   `ciss_free` (STAILQ cycle/corruption).

Additionally the CAM data buffer keeps being DMA'd per the clobbered SG
state — the in-flight command is corrupted mid-execution.

## Reachability / threat model
Precondition: the adapter returns a fatal command status for the
Notify-on-Event command (`CISS_CMD_STATUS_PROTOCOL_ERROR`,
`CISS_CMD_STATUS_HARDWARE_ERROR`, `CONNECTION_LOST`, `ABORT_FAILED`, …).
That is a real-world condition on distressed/flaky Smart Array firmware —
precisely the situations that also trip the heartbeat watchdog. No
unprivileged-local trigger: this is a firmware-response-driven defect
(same trust boundary as DF-1189..DF-1192).

## Verification (no HP Smart Array on the audit guest)
`harness.c` models the request pool, free queue, notify state machine and
completion dispatch 1:1 (kernel line cites inline). Baseline run
(`run.log`, stable across run.2/run.3):
- step4: `tag1 now posts=3 (DOUBLE POST)` with the CAM buffer retained;
- step5: `CAM callback (xpt_done) ran 3 time(s) for ONE ccb`;
- `[BUG REPRODUCED]`.
`-DFIXED` replica (adds `sc->ciss_periodic_notify = NULL;` to the fatal
path): `periodic_notify = NULL (cleared)` — the chain restarts on a fresh
request, CAM request untouched.

## Fix validation
- `fix.diff`: one statement (`sc->ciss_periodic_notify = NULL;`) before
  `ciss_release_request(cr)` in the fatal path.
- `fix_apply.log`: clean dry-run on guest `/usr/src`.
- `fix_build.log`: `ciss.ko` rebuilt with all 7 ciss fixes at `-Werror`,
  link rc=0.
- Harness `-DFIXED` run: dangling reuse GONE.

**Bottom line: reproduced (harness-level, firmware-gated path); request
lifetime defect leading to double completion / CAM CCB UAF; fix validated at
compile + replica level.**

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