# DF-1289 — mly CAM CCB sense buffer heap overflow

## Verdict
**NOT REPRODUCED** — real source-level bug confirmed by line-by-line trace;
**unreachable at runtime on this guest** because the `mly` driver attaches
only to Mylex PCI RAID HBAs (PCI vendor 1069) and the audit QEMU/KVM guest has
none.

## Mechanism (verified)
- `mly.c:1567`: `mc->mc_sense = sp->status.sense_length;` — controller-DMA-derived u8.
- `mly.c:2354`: SCSI_STATUS_CHECK_COND handler.
- `mly.c:2356`: `bzero(&csio->sense_data, SSD_FULL_SIZE);` — destination is SSD_FULL_SIZE=32 bytes.
- `mly.c:2357`: `bcopy(mc->mc_packet, &csio->sense_data, mc->mc_sense);` — **no clamp**. mc_sense ∈ [0,255] → up to 223-byte overflow.

Sink confirmed; no bounds check anywhere upstream. The sibling finding
DF-1281 (`mly.c:1129-1131`) is the same defect on a different code path and
was independently fixed via the same `min(.., SSD_FULL_SIZE)` clamp on the
user-command path. DF-1289 is the CAM-completion path that the sibling fix did
not cover.

## Why not triggered on this guest
- `pciconf -l`: only Intel PIIX3/PIIX4 + virtio-net + virtio-blk + std-VGA. No vendor-1069 device.
- `kldstat -v | grep mly`: the `pci/mly` driver is compiled in but never attaches (`devclass_get_softc` ⇒ NULL).
- No syscall path leads to `mly_cam_complete` — it fires only from the HBA's command-completion interrupt.

Per Phase 4(d) of the procedure (genuinely not reachable on this kernel — the
sink is behind an absent device), this is recorded as `not_reproduced`. The
bug itself is real and the fix is necessary.

## Fix
`fix.diff` clamps the bcopy length:
```c
bcopy(mc->mc_packet, &csio->sense_data,
      min(mc->mc_sense, SSD_FULL_SIZE));
```
Matches the approach taken for DF-1281. `min()` and `SSD_FULL_SIZE` are
already in scope (`<sys/systm.h>` is included at line 31; `scsi_all.h` is
pulled in via the CAM headers).

## Fix validation
The fix compiles cleanly as part of `make -j6 nativekernel KERNCONF=X86_64_GENERIC` (see `fix_build.log`). A runtime before/after test is **not
testable** on this guest: there is no Mylex HBA, so neither the unpatched nor
the patched kernel can reach the affected code path. `fix_status: not_testable`
reflects this honestly.

## Realistic impact ceiling
Heap overflow of up to 223 attacker-influenced bytes into a CAM CCB, but only
reachable from a malicious/faulty Mylex HBA (hostile-PCI-device threat model).
On default GENERIC (INVARIANTS ON) the slab checks would likely catch the
overflow; on a non-debug kernel the primitive is in principle groomable. The
fix is correct and minimal regardless of exploitability.