DF-2468 reproduction: malicious target drives getSenseData with crafted sense.

mtarget2468 (LUN-0-only): completes iSCSI login, serves valid INQUIRY (da0
appears) and GOOD READ CAPACITY, and returns CHECK CONDITION with a crafted
Data Segment = [sense_len=252 (BE) + 8 bytes sense] but DSLength=10, on every
non-probe SCSI command.

== CAM LUN enumeration proves getSenseData runs ==
On the earlier "serve CHECK CONDITION for all non-INQUIRY" mtarget variant,
the iSCSI initiator enumerated 2600+ LUNs (da0..da2635) because the mtarget
answered INQUIRY for every LUN.  Every CHECK CONDITION response during that
storm ran getSenseData(status, ccb, pq) with sense_len=252 > DSLength=10 ->
kmalloc(252, M_ISCSI, M_WAITOK) [NO M_ZERO], i_mbufcopy copied the 10 real DS
bytes, leaving bp[10..251] = stale kernel heap; bcopy(bp+2, sense, min(252,
scsi->sense_len)) copied stale heap into the CCB sense_data.  mtarget log
showed cmdsn > 19000 (ISCSI_INITIATOR processing each through getSenseData).

== Userspace: camcontrol pass-through returns the CHECK CONDITION sense ==
(LUN-0-only mtarget; da0 appeared at scbus2 target 0 lun 0)
  camcontrol cmd da0 -v -c "03 00 00 00 fc 00"   (REQUEST SENSE)
  -> CAM Status: SCSI Status Error
  -> SCSI Status: Check Condition
  -> ILLEGAL REQUEST info?:26000a00 asc:0,0
  -> No additional sense information
The CHECK CONDITION sense (CAM_AUTOSNS_VALID, iscsi_subr.c:207) IS returned to
userspace -- confirming the leak path reaches userspace via a pass-through CCB.
The "26000a00" are the crafted bytes (0x26 0x00 0x0a 0x00); camcontrol PARSES
the sense rather than raw-dumping, so the stale-heap tail (bytes after the 8
crafted) is not shown by camcontrol.

== Raw byte capture blocked by a separate panic ==
A custom pass-through (sense2468) to raw-dump the sense buffer triggered a
DIFFERENT panic, unrelated to DF-2468:
  panic: assertion "LWKT_TOKEN_HELD_EXCL(&mp_token)" failed in
         sim_lock_assert_owned at /usr/src/sys/bus/cam/cam_sim.c:104
(a CAM SIM locking assertion from the iSCSI+pass-through interaction).  This
blocked a clean before/after raw-byte leak comparison; it is a distinct
pre-existing issue, not the DF-2468 leak.

CONCLUSION: the getSenseData leak primitive is reproduced (malicious target
drives it; kmalloc-without-M_ZERO + unbounded sense_len confirmed by source;
the sense reaches userspace via CAM_AUTOSNS_VALID).  Byte-level raw capture is
blocked by the separate CAM locking panic.  Impact = remote kernel heap info
leak into CCB sense buffers (KASLR/slab-layout disclosure ceiling).