# VERDICT — DF-1547: advansys cdb_len LRAM overflow + csio tail read-over

## Verdict

**INCONCLUSIVE (HW/module gated) — source-level confirmed, fix validated.**

The bug is real and present in master DEV source at `sys/dev/disk/advansys/advansys.c:548,565, advlib.c:1816-1818`, but
the affected driver attaches only to hardware not present in the audit QEMU
guest (only virtio+PIIX3 PCI devices, no AMD/Intel GPUs, no ath NICs, no
AdvanSys SCSI, no mfi/tws/mrsas RAID, etc.), so it cannot be live-triggered
here. The `fix.diff` applies cleanly and the patched kernel compiles with
`-Werror` (combined build rc=0; see `fix_apply.log`).

## Mechanism (cited path → primitive → effect)

scsiq.cdbptr = csio->cdb_io.cdb_bytes (548). scsiq.q2.cdb_len = csio->cdb_len NO clamp at 565. cdb_len is u8. cdb_bytes is u8[IOCDBLEN=16]. Sink: advlib.c:1816-1818 adv_write_lram_16_multi at offset ADV_SCSIQ_CDB_BEG=36 of ADV_QBLK_SIZE=64 slot -> 28-byte CDB region. cdb_len=255 OUTSW 254 bytes -> 226 past slot -> 4 firmware queues corrupted. Also over-reads cdb_bytes for cdb_len>16 -> leaks sense_data/sense_len/sglist_cnt/resid/msg_ptr fields.

## Reachability on this guest

No — `sys/dev/disk/advansys/advansys.c:548` is in a driver/module that only attaches
to hardware absent from the audit guest. The trigger requires the relevant
PCI device (or, for VBIOS-driven GPU paths, the actual GPU + a crafted VBIOS
loaded by root or via VFIO passthrough).

## Phase 6 — escalation potential

This is a DMA overflow + adjacent memory over-read primitive. On real hardware
it could be triggered by an unprivileged user (via crafted packets for the
NIC findings, via DRM ioctls for the GPU findings, via CAM/pass for the SCSI
findings). On **this guest** there is no live primitive to convert. Per
Phase 6 rules this is the "dead/unreachable at runtime on this guest" hard
blocker; the primitive is proven at the source/harness level (the cited
path:line is real and unfixed in master).

Realistic impact ceiling on suitable HW: **kernel memory corruption of 4 firmware queues + info leak to firmware (and back to CAM)**.

## Phase 8 — fix validation

`fix.diff` is a minimal, targeted fix at the root cause confirmed above.

- **Applied cleanly** with `patch -p1 --forward` (verified in `fix_apply.log`).
- **Compiled with `-Werror`** as part of the combined
  `make -j6 nativekernel KERNCONF=X86_64_GENERIC` build (kernel build rc=0;
  see `manifest.json`).
- For HW-gated findings the patched code path is not exercisable on this
  guest, so the fix is validated at the apply + compile level only.

Fix approach: Clamp scsiq.q2.cdb_len to imin(csio->cdb_len, IOCDBLEN) in advrunqueue.

## PoC changes

Source-level confirmation only; no userspace harness written because the bug
cannot be exercised on this guest without the relevant HW. The placeholder
`build.sh`/`run.sh` echo pointers to `VERDICT.md` and the module/kernel
rebuild path.