DF-3929 — mly: mly_done() completion slot lacks lower-bound check → mly_command[-1] OOB write + TAILQ pointer writes

Build / Run

Triggered purely by the controller's completion traffic (hardware mailbox status register read or memory-mailbox status ring walk). On hardware, a card returning command_id 0 in a completion (buggy/hostile firmware) hits it from the very first interrupt — no user action required beyond having the driver attached.

Lab observation: QEMU device model returning status_mailbox value 0x0000 (or an mmbox status entry with command_id=0) → immediate OOB write on completion.

Expected result

mc = &sc->mly_command[0 - MLY_SLOT_START] = mly_command[-1] — three direct field writes plus TAILQ_REMOVE() pointer writes into the tail of mly_btl[], then the fake command is threaded onto the complete queue and its mc_complete (garbage from controller-fed btl fields) is called.

Hardware-gated (no mly controller in the audit guest): source-certain. See VERDICT.md.

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.