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.

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.