# VERDICT — DF-3846 (sc->map_update_cmd never cleared: dangling pooled command aborted at shutdown)

**status: inconclusive (hardware-gated; dangling-pointer structure source-certain)**
**confidence: certain (lifetime defect at source level)** · **class: stale-handle / cross-command abort (logic confusion; in-bounds indices)**

## The defect (source)

`sc->map_update_cmd` is assigned once — `mrsas_sync_map_info()`, mrsas.c:3239 — and **cleared
nowhere** (grep across mrsas*.c: only writers are 3239; only reader is mrsas_shutdown_ctlr,
mrsas.c:3041-3042).

Every completion path for a RAID-map sync command returns the mfi command to the free pool
*without* touching `sc->map_update_cmd`:

- `mrsas_complete_mptmfi_passthru()` map branch, success/normal: `mrsas_release_mfi_cmd(cmd)`
  at **mrsas.c:2960** (and the map_id++ path re-issues a new sync which re-points it at 3239 —
  but only when a new sync actually fires);
- map-sync failed `MFI_STAT_NOT_FOUND`: `mrsas_release_mfi_cmd(cmd)` at **mrsas.c:2953** then
  `break` — **no new sync is issued**, so `sc->map_update_cmd` is left dangling to a command
  that is now on the free list;
- `mrsas_reset_ctrl()` re-fire loop: for `MR_DCMD_LD_MAP_GET_INFO` opcodes it does
  `mrsas_release_mfi_cmd(mfi_cmd); mrsas_release_mpt_cmd(mpt_cmd);` at **mrsas.c:2454-2455**
  — again leaving `sc->map_update_cmd` pointing at the released command.

## Consequence

At detach/shutdown, `mrsas_shutdown_ctlr()` (mrsas.c:3038-3042) does:

```c
if (sc->map_update_cmd)
    mrsas_issue_blocked_abort_cmd(sc, sc->map_update_cmd);
```

`mrsas_issue_blocked_abort_cmd` (mrsas.c:3465-3517) builds the abort frame from
`cmd_to_abort->index` and `cmd_to_abort->frame_phys_addr` (mrsas.c:3486-3488). If the pooled
command has been recycled in the meantime (its 32-entry pool is shared by all internal and
ioctl passthrough traffic), the firmware is asked to abort **whatever command now occupies
that index/frame** — an in-flight ioctl passthrough of another thread or an internal DCMD.
That command's waiter receives a spurious abort completion (`mrsas_complete_abort` /
`mrsas_wakeup`), i.e. an unrelated management command fails at shutdown time. All indices
remain in-bounds; the pooled objects are permanent allocations, so this is a stale-handle
logic defect (wrong-command abort / status confusion), not a wild memory access — hence
Low severity.

## Why not reproduced on the guest
Requires an attached MegaRAID controller that completes (or fails with NOT_FOUND) a map sync
and then a shutdown during which the command slot was recycled. The guest has mrsas compiled
in but no LSI device (run.log). Source structure is certain: there is no clearing store to
`sc->map_update_cmd` anywhere in the driver.

## Fix
`fix.diff`: null the pointer at all three release sites and re-check the command is still the
registered map-sync command before aborting at shutdown.

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