DF-3831 — trm(4) has no CCB timeout handler (callout commented out) — lost commands wedge the SIM queue forever

• File: sys/dev/disk/trm/trm.c (pass 2)
• Class: CWE-1089 (missing recovery path / unbounded wait) — Local DoS
• Severity: Low (requires a hung/malicious SCSI target on a Tekram bus)

Build / Run / Expected

Hardware-gated (no Tekram HBA on the audit guest — env.txt). On hardware, the trigger is any command that is accepted by a target but never completed (device that stalls the data phase, yanked disk, malicious SCSI target emulation):

# start I/O through trm(4), then hang the target (or unplug it mid-transfer)
dd if=/dev/da0 of=/dev/null bs=1m

Expected on vulnerable code: the CCB never times out — CAM's periph error recovery (which relies on ccb_h.timeout_ch armed by the SIM) never fires; the trb SIM stays wedged until reboot.

Root cause

trm_ExecuteSRB — trm.c:470-474:

static void
trm_ExecuteSRB(...)
{
    ...
#if 0
    /* XXX Need a timeout handler */
    callout_reset(&ccb->ccb_h.timeout_ch, (ccb->ccb_h.timeout * hz) / 1000,
              trmtimeout, srb);
#endif
    trm_SendSRB(pACB, pSRB);

The driver author never implemented the timeout. There is also no ccb_h.timeout_ch callout_stop in the completion path (trm_SRBdone) — consistent with it never being armed.

Aggravator: trm_ExecuteSRB ignores the error argument of the bus_dmamap callback (trm.c:414) — if bus_dmamap_load fails (e.g. EFBIG for a >33-segment pass(4) buffer against TRM_NSEG = btoc(MAXPHYS)+1, trm.h:98), the CCB is either orphaned (never queued, never done) or run with zero data, and without a timeout there is no recovery in either case.

VERDICT — DF-3831

status: inconclusive (source-certain, hardware-gated) — reproduced: 0 — guest impact: none.

Trace

1. The only timeout machinery in the whole driver is the #if 0 block at trm.c:470-474, annotated "XXX Need a timeout handler" — trmtimeout does not exist anywhere in the tree (grep -rn trmtimeout sys/ -> only that comment).
2. CAM contract: the SIM arms ccb->ccb_h.timeout_ch when it accepts a CCB; the periph layer (da/pass) depends on that callout to drive error recovery. With it never armed, a command that the chip never completes (target stops responding mid-phase — the exact scenario the selection-timeout logic at trm.c:1217-1229 only partially covers: it handles selection timeouts, not mid-transfer stalls) leaves the SRB on pDCB->pGoingSRB forever and the SIM queue frozen forever (single-command-per-target activation, trm.c:338-376).
3. Aggravator (same no-recovery family): the bus_dmamap_load callback trm_ExecuteSRB(void *arg, bus_dma_segment_t *dm_segs, int nseg, int error) at trm.c:414 never inspects error. On a load failure the CCB is orphaned without xpt_done — and with no timeout there is no path that ever completes it -> permanent hang of that device queue plus a leaked SRB slot.

Why inconclusive, not false-positive

The missing callout is unambiguous in source (the author's own XXX concedes it). It cannot be exercised on the audit guest because trm(4) requires a Tekram DC395U/U2 PCI adapter (trm.c:3677-3688) and the guest has none (env.txt). On hardware the failure needs a hung/removed/malicious target — ordinary operational hazard for parallel SCSI.

Fix

fix.diff arms the ccb timeout callout in trm_ExecuteSRB, stops it in trm_SRBdone, adds the missing error check for the dmamap callback (fail the CCB instead of orphaning it), and adds a minimal trm_timeout that resets the bus (reusing the existing trm_reset machinery). git-apply --check passes against sys/dev/disk/trm/trm.c.

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.