# DF-4244 — dpt_detect_cache() log-page walk bounded by device-fed length, not by the 512-byte transfer

The HBA is asked for exactly 512 bytes of log page (cp_datalen = htonl(512),
dpt_scsi.c:618), DMA'd into `buff = &dccb[1]`. The parameter walk's bound,
however, is `bytes = DPT_HCP_LENGTH(buff)` (dpt_scsi.c:648) — the page
header's 16-bit length field **written by the controller** (dpt.h:341),
i.e. up to 65539 — and each `DPT_HCP_NEXT(param)` step reads param[3]
(another device-fed byte) *before* the bound check at dpt_scsi.c:663-669.
A hostile/faulty controller that reports a large page length walks `param`
up to ~64 KB past the 512-byte transfer, reading kernel memory the device
never wrote (stale sg-page contents, then adjacent kernel memory past the
page). The values only influence cache_type (no direct disclosure), but a
walk into an unmapped page faults at attach → kernel panic (DoS ceiling).

## Reproduce (arithmetic proof, no hardware needed)
- build: `cc -O2 -Wall -o dpt_df4244_walk dpt_df4244_walk.c`
- run: `./dpt_df4244_walk`
- expected (guest transcript in run.log):
    bytes=65539, DMA=512, page=4096
    16383 accepted steps, farthest offset buff+65536
    16257 iterations read outside the 512-byte DMA buffer
    15361 of those read past the entire 4096-byte sg page