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

## Finding
`mly_cam_complete` at `sys/dev/raid/mly/mly.c:2357` copies controller-supplied
sense data into a CAM CCB's `sense_data` field with no length clamp:

```c
bcopy(mc->mc_packet, &csio->sense_data, mc->mc_sense);
```

`mc->mc_sense` is a `u_int8_t` (`sys/dev/raid/mly/mlyvar.h:132`) loaded directly
from the controller status mailbox at `mly.c:1567`:
`mc->mc_sense = sp->status.sense_length;`. The destination `sense_data` is
`sizeof(struct scsi_sense_data) = SSD_FULL_SIZE = 32` bytes
(`sys/bus/cam/scsi/scsi_all.h:953`). A buggy or malicious Mylex AcceleRAID/
eXtremeRAID controller that returns `sense_length` up to 255 therefore drives a
**heap overflow of up to 223 bytes** past `csio->sense_data`.

## Why we did not reproduce at runtime
The `mly` driver attaches only to Mylex PCI RAID HBAs (vendor 1069). The
audit guest is a QEMU/KVM VM with **no Mylex hardware** — the only PCI devices
present are Intel PIIX3/PIIX4 + virtio-net + virtio-blk + QEMU std VGA
(`pciconf -l` in `env.txt`). The driver is compiled into the GENERIC kernel
(`sys/config/X86_64_GENERIC:122  device mly`) but `devclass_get_softc` returns
NULL for every unit, so the buggy path is unreachable on this guest. There is
no userspace syscall path to the affected function — it is only invoked from
the controller's command-completion interrupt handler.

## Source-level confirmation
- `sys/dev/raid/mly/mly.c:2357` — `bcopy(mc->mc_packet, &csio->sense_data, mc->mc_sense);` (no clamp)
- `sys/dev/raid/mly/mlyvar.h:132` — `u_int8_t mc_sense;` (range 0..255)
- `sys/dev/raid/mly/mly.c:1567` — `mc->mc_sense = sp->status.sense_length;` (controller-DMA-derived)
- `sys/bus/cam/scsi/scsi_all.h:953` — `#define SSD_FULL_SIZE sizeof(struct scsi_sense_data)` = 32

The bug is real. The sibling finding DF-1281 reports the same defect on the
`mly_user_command` path (`mly.c:1129-1131`).

## How to reproduce the source defect
This is a hardware-driver finding that cannot be exercised on a guest lacking
the device. To validate the fix, build the patched kernel (see `fix.diff`) —
the length is now clamped: `bcopy(..., min(mc->mc_sense, SSD_FULL_SIZE));`.

## Realistic impact ceiling
A malicious or faulty Mylex HBA (or a PCI-attached FPGA the attacker controls)
can overflow a CAM `ccb_hdr_path`/`csio` allocation by up to 223 bytes. Because
the CCB is allocated from a generic CAM bucket, this is a kernel heap overflow
of attacker-shaped bytes. On the default GENERIC kernel (INVARIANTS ON) the
slab poisoning checks would likely catch the corruption; on a non-debug kernel
the primitive could in principle be groomed for privilege escalation. The
realistic threat model is "hostile PCI device" or "faulty HBA firmware",
which is narrower than an unprivileged-local attack.

## Build
No PoC binary — this finding is not exercisable without the HBA. The fix
compiles cleanly (see `fix_build.log`).