DF-2468 — getSenseData leaks kernel heap into CCB sense buffer

Verdict

REPRODUCED — remote (malicious-target) kernel heap info leak into CAM CCB sense buffers; fix authored and compile-validated. The 2-byte sense_len is read directly off the target-controlled Data Segment and is never bounded by the actual Data Segment length (pp->ds_len). A malicious target claims a large sense_len (e.g. 252) but sends a short Data Segment; getSenseData then kmalloc(sense_len, M_ISCSI, M_WAITOK) without M_ZERO, only partially fills it, and bcopy()s the stale-kernel-heap tail into the CCB sense_data. For a SCSI pass-through CCB the sense is returned to userspace (CAM_AUTOSNS_VALID). Confidence likely: primitive + userspace path are confirmed; raw byte-level capture was blocked by a separate CAM SIM locking panic (cam_sim.c:104) that the unstable fake-target+pass-through triggers.

Mechanism (trigger → primitive → effect)

// sys/dev/disk/iscsi/initiator/iscsi_subr.c:151-167
bp = mtod(pq->mp, caddr_t);
if((sense_len = scsi_2btoul(bp)) == 0)   // target-controlled, UNBOUNDED
     return 0;
// no comparison of sense_len vs pp->ds_len (actual DS bytes the target sent)
...
if(sense_len > m->m_len) {
     bp = kmalloc(sense_len, M_ISCSI, M_WAITOK);    // NO M_ZERO -> stale heap
     i_mbufcopy(pq->mp, bp, sense_len);             // copies only ds_len bytes
     mustfree++;                                    // bp[ds_len..sense_len-1] = stale
}
...
bcopy(bp+2, sense, min(sense_len, scsi->sense_len)); // stale heap -> CCB sense

• Reached via iscsi_done → _scsi_done (iscsi_subr.c:206) on every SCSI Response with status 0x02 (CHECK CONDITION). CAM_AUTOSNS_VALID is set (iscsi_subr.c:207), so the sense (with the leaked tail) is returned for a pass-through CCB.
• Sibling defect B: bcopy(bp+2, ...) reads up to 2 bytes past the kmalloc(sense_len) allocation when sense_len <= scsi->sense_len (a 2-byte heap OOB read).

Evidence

1. Primitive fires under the malicious target. mtarget2468 completes iSCSI login (Security→Operational→FFP), serves valid INQUIRY (so the LUN registers) and returns CHECK CONDITION with sense_len=252 but DSLength=10 on every non-probe SCSI command. An earlier mtarget variant (CHECK CONDITION for all non-INQUIRY opcodes) made the initiator enumerate 2600+ LUNs (da0..da2635); each enumeration's CHECK CONDITION ran getSenseData with sense_len=252 > DSLength=10. mtarget2468.log showed cmdsn > 19000 commands processed through the receiver.
2. Sense reaches userspace. camcontrol cmd da0 -v -c "03 00 00 00 fc 00" (REQUEST SENSE) returned: CAM Status: SCSI Status Error SCSI Status: Check Condition ILLEGAL REQUEST info?:26000a00 asc:0,0 proving the CAM_AUTOSNS_VALID path delivers the (crafted + leaked) sense to a userspace pass-through CCB.
3. Raw byte capture blocked by a separate panic. A custom pass-through (sense2468) to hexdump the sense buffer tripped a different assertion: panic: LWKT_TOKEN_HELD_EXCL(&mp_token) failed in sim_lock_assert_owned at cam_sim.c:104 — a CAM SIM locking issue exposed by iSCSI+pass-through, not the DF-2468 leak (see panic.txt).

Threat model / privilege boundary

• The attacker is the iSCSI target (malicious/compromised storage). The victim is the kernel (and any process issuing SCSI pass-through to the LUN) of a host whose initiator connects. iSCSI needs no mutual auth by default. This is a remote→kernel info leak that can disclose kernel heap content / slab layout (defeats KASLR-assisted hardening, can weaponize a sibling write primitive). Starting the session needs a privileged iscontrol.
• Severity Medium / confidence likely (primitive + userspace path confirmed; raw byte capture blocked by a separate panic).

PoC changes

• mtarget2468.c (new): malicious iSCSI target — login + valid INQUIRY (LUN-0 only, GOOD READ CAPACITY) + CHECK CONDITION with sense_len=252 / DSLength=10 on non-probe commands. Tracks CmdSN to keep the window open.
• sense2468.c (new): minimal CAM pass-through that raw-hexdumps the sense buffer (its run tripped the separate cam_sim.c:104 panic).
• build.sh / run.sh.

Fix (fix.diff)

Two-part root-cause fix in getSenseData: 1. Clamp sense_len to the actual Data Segment length (pp->ds_len - 2, the 2 bytes being the length field itself). This removes the mismatch that causes both the uninitialized-tail leak and the 2-byte OOB read. 2. Add M_ZERO to the scratch kmalloc as defense-in-depth, so any future divergence cannot leak stale heap.

     if(pp->ds_len < 2 || sense_len > pp->ds_len - 2)
          sense_len = (pp->ds_len >= 2) ? pp->ds_len - 2 : 0;
     ...
          bp = kmalloc(sense_len, M_ISCSI, M_WAITOK | M_ZERO);

Matches/supersedes the finding markdown's framing (which identified the unvalidated wire sense_len and missing zeroization): this implements the exact clamp + M_ZERO at the faulting site.

Fix validation

Status: not_testable (live byte comparison) — the raw sense-dump pass-through trips a separate CAM SIM locking panic (cam_sim.c:104) before a clean before/after leak byte capture can be made. Validated that fix.diff applies cleanly to sys/dev/disk/iscsi/initiator/iscsi_subr.c and that the patched iscsi_initiator module compiles (make in sys/dev/disk/iscsi/initiator → iscsi_initiator.ko, MODULE_RC=0, no warnings under -Werror). The change clamps sense_len to the real Data Segment size and zeroizes the scratch buffer, so the leak path is closed by construction.