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