# DF-3929 verdict narrative

## Reproduced?
No (hardware-gated).  Source-level certainty: certain — pure register/ring
walk arithmetic.

## Root cause chain (path:line)

Slot regulation is 1-based on purpose:

  mlyvar.h:153-154
  ```
  #define MLY_SLOT_START   1
  #define MLY_SLOT_MAX     (MLY_SLOT_START + MLY_MAX_COMMANDS)   /* 257 */
  ```
  ("We can't use slot 0 due to the memory mailbox implementation.")

Both completion paths check only the UPPER bound:

  mly.c:1533-1543 (hardware mailbox):
  ```c
  slot = MLY_GET_REG2(sc, sc->mly_status_mailbox);
  if (slot < MLY_SLOT_MAX) {                       /* no slot >= MLY_SLOT_START */
      mc = &sc->mly_command[slot - MLY_SLOT_START];  /* slot==0 -> index -1 */
      mc->mc_status = ...
      mc->mc_sense  = ...
      mc->mc_resid  = ...
      mly_remove_busy(mc);                          /* TAILQ_REMOVE */
  ```

  mly.c:1554-1582 (memory mailbox ring walk): identical
  `if (slot < MLY_SLOT_MAX)` at :1564 with `sc->mly_command[slot -
  MLY_SLOT_START]` at :1565.

`slot` is `u_int16_t` fed by firmware (16-bit status mailbox read at :1534, or
`sp->status.command_id` at :1563).  slot==0 passes `< 257` and yields
`&sc->mly_command[-1]` — one `struct mly_command` (~104B) BEFORE the array,
which overlays the tail of `mly_btl[5][*]` (softc layout, mlyvar.h:206-209).

What lands there:

1. Direct writes of firmware-fed values: `mc_status` (u16), `mc_sense` (u8),
   `mc_resid` (u32) — into btl fields.
2. `mly_remove_busy(mc)` → `TAILQ_REMOVE(&sc->mly_busy, mc, mc_link)`
   (mlyvar.h:345-352): reads `mc->mc_link.tqe_next/tqe_prev` from btl memory —
   `mb_flags`/`mb_name[]`/`mb_state` regions.  mb_state/mb_speed/mb_width are
   firmware-fed ints (mly.c:928-930 from GETPHYSDEVINFOVALID); then executes
   `if (tqe_next) tqe_next->tqe_prev = tqe_prev; *tqe_prev = tqe_next;` —
   write-what-where style kernel writes with firmware-influenced pointers.
3. `mly_enqueue_complete(mc)` threads the fake entry onto the complete queue;
   `mly_complete()` (mly.c:1612-1634) then invokes `mc_complete(mc)` — a
   function pointer read from the same btl memory — firmware-influenced
   indirect call.

## Same-surface aggravators (same trust boundary, not separately filed)
- Duplicate completion for an already-completed slot: `mly_remove_busy()` on
  a command that is on the free list corrupts both TAILQs (mly.c:1540/1569).
- The mmbox walk loop (mly.c:1555-1582) is bounded (each iteration clears the
  flag), so no unbounded walk there.

## Threat model
Same as DF-1290/DF-1289: malicious/buggy controller.  Note this one is
remotely *reachable without any local user action* — completions arrive from
the card on their own.

## Impact
Kernel memory corruption inside the softc with pointer-write and indirect-call
primitives derived from firmware-fed fields; panic to potential code execution
given a hostile device.

## Fix
`slot >= MLY_SLOT_START && slot < MLY_SLOT_MAX` in both paths — fix.diff.

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