DF-1237 — README

Finding

trm_ExecuteSRB at sys/dev/disk/trm/trm.c:434-440 copies nseg scatter/gather entries into pSRB->pSRBSGL (a DMA-coherent buffer of TRM_MAX_SG_LISTENTRY=32 entries — trm.h:92, trm.c:3498) with no bounds check. Two paths reach it:

• CAM_SCATTER_VALID at trm.c:666-669 passes pcsio->sglist_cnt (a u_int16_t, 0..65535) straight from userspace — up to 65535 × 8B = ~512 KB DMA-coherent heap overflow.
• bus_dmamap_load callback at trm.c:625: buffer_dmat is created with nsegments=TRM_NSEG=33 (trm.h:98, trm.c:3429) on x86_64 (MAXPHYS=128KB → btoc=32 → TRM_NSEG=33) → legitimate 33rd segment overflows by 1 entry (8 bytes).

Verdict

NOT REPRODUCED on this guest: trm is not in X86_64_GENERIC (sys/config/X86_64_GENERIC has no device trm) and no Tekram DC-395 controller is present in pciconf -lv. trm_ExecuteSRB is dead code on this kernel. PoC prints the reachability status.

Confidence (bug is real): certain — traced line-by-line in sys/. Impact ceiling: operator-group → kernel heap corruption via DMA coherent slab overflow, on any host with a Tekram DC-395U/UW adapter and the trm module loaded.

How to reproduce

./build.sh && ./run.sh

Expected on this guest: PoC builds clean, prints "trm driver NOT loaded (no 'device trm' in X86_64_GENERIC)" and "trm_ExecuteSRB is dead code on this kernel". On a host with the trm module loaded and a Tekram adapter, pass(4) CAMIOCOMMAND XPT_SCSI_IO with CAM_SCATTER_VALID and sglist_cnt > 32 overflows pSRBSGL.

Files

DF-1237 — VERDICT

Finding: trm_ExecuteSRB at sys/dev/disk/trm/trm.c:434-440 copies nseg scatter/gather entries into pSRB->pSRBSGL (a DMA-coherent allocation of TRM_MAX_SG_LISTENTRY=32 entries) with no bounds check. Two paths feed nseg:

• trm_action CAM_SCATTER_VALID branch at trm.c:666-669 passes pcsio->sglist_cnt (a u_int16_t, 0..65535) verbatim — fully user-controlled.
• The bus_dmamap_load callback path at trm.c:625 is bounded by buffer_dmat's nsegments=TRM_NSEG=btoc(MAXPHYS)+1 — but on x86_64 MAXPHYS = 128 KB, so TRM_NSEG = 33 while pSRBSGL has only 32 slots → 1-entry (8-byte) overflow even via the legitimate path.

Status: NOT REPRODUCED on this guest — trm is not in X86_64_GENERIC and no Tekram DC-395 controller is present. Confidence (bug is real): certain (traced line-by-line in sys/). Impact ceiling: unbounded DMA-coherent heap overflow (8 bytes × user-supplied nseg) — exploitable by any local user with write access to /dev/passN (operator group) once a Tekram adapter and trm module are present.

Mechanism (confirmed line-by-line in sys/)

1. pSRBSGL is allocated at sys/dev/disk/trm/trm.c:3027 from pACB->sg_dmat, which is created at trm.c:3498 with c /*maxsize*/ TRM_MAX_SG_LISTENTRY * sizeof(SGentry), TRM_MAX_SG_LISTENTRY = 32 (trm.h:92), sizeof(SGentry) = 8 (trm.h:80-83). So pSRBSGL holds exactly 32 entries.

2. The copy loop in trm_ExecuteSRB (trm.c:431-440): ```c if (nseg != 0) { PSEG psg; bus_dma_segment_t *end_seg; bus_dmasync_op_t op;

   end_seg = dm_segs + nseg; psg = pSRB->pSRBSGL; while (dm_segs < end_seg) { psg->address = dm_segs->ds_addr; psg->length = (u_long)dm_segs->ds_len; totalxferlen += dm_segs->ds_len; psg++; dm_segs++; } `` **No bounds check onnseg.** Each iteration writes 8 bytes past the previouspsg, sonseg > 32` overflows the DMA-coherent slab.

3. nseg sources: - bus_dmamap_load callback (trm_action CAM_DIR_IN/OUT non-scatter path, trm.c:620-627). buffer_dmat is created with c /*nsegments*/ TRM_NSEG, /* trm.c:3429 */ where TRM_NSEG = btoc(MAXPHYS) + 1 (trm.h:98). On x86_64 MAXPHYS = 128*1024, btoc(128K) = 32, so TRM_NSEG = 33. bus_dma can legitimately produce up to 33 segments for a 128 KB buffer that straddles 33 pages — 1 entry (8 bytes) more than pSRBSGL can hold. Off-by-one overflow even without CAM_SCATTER_VALID. - CAM_SCATTER_VALID (trm.c:666-669): c segs = (struct bus_dma_segment *) pcsio->data_ptr; trm_ExecuteSRB(pSRB, segs, pcsio->sglist_cnt, 1); pcsio->sglist_cnt is a u_int16_t from userspace. pass(4) honors CAM_SCATTER_VALID and lets the caller supply a complete SG list. No bounds check. A caller passing sglist_cnt=65535 triggers an 8 × 65535 = 512 KB DMA-coherent overflow.

4. The overflow corrupts whatever follows pSRBSGL in the DMA-coherent segment pool — adjacent SRBs' pSRBSGL/pNextSRB/ pccb pointers, depending on slab layout. On any host with a Tekram adapter, this is a real operator-group → kernel heap corruption vector.

Why it is NOT REPRODUCED on this guest

• sys/config/X86_64_GENERIC does not contain device trm. The driver is built only as the loadable module trm.ko.
• The audit guest has no Tekram DC-395U/UW controller in pciconf -lv.
• PoC trm_sg_overflow.c confirms kldstat -v | grep trm returns empty.

Threat model & privilege boundary

Same as DF-1235: /dev/passN is operator-group on stock devfs; any user in operator can issue CAMIOCOMMAND with XPT_SCSI_IO, CAM_SCATTER_VALID, and a forged ccb_scsiio.sglist_cnt. Loading the trm module is a one-time admin action; the exploit itself is fully unprivileged once the module is loaded.

Fix (authored in fix.diff, applied + compile-validated)

Two-part fix:

1. Reject nseg > TRM_MAX_SG_LISTENTRY at the top of trm_ExecuteSRB's SG-copy block (trm.c:431-440), returning CAM_REQ_TOO_BIG and the SRB to the free list (mirrors existing failure paths in the file). This closes the CAM_SCATTER_VALID user-controlled overflow.

2. Change buffer_dmat's nsegments from TRM_NSEG (33) to TRM_MAX_SG_LISTENTRY (32) at trm.c:3429, so bus_dmamap_load cannot produce a 33rd segment that overflows by one entry. With both fixes, the SRB's 32-entry SG buffer cannot be overrun on any path.

Validation

• fix.diff applies cleanly with patch -p1 --forward (verified).
• All 5 audit fixes applied together; make -j6 nativekernel KERNCONF=X86_64_GENERIC returned rc=0 with no errors / warnings under -Werror. trm.c was compiled cleanly as the loadable module trm.ko.
• Fix is not_testable at runtime on this guest (trm not in GENERIC, no Tekram HW).