# DF-1086 — crom_parse_text CROM_END check treats crc_len as bytes (OOB read)

## Verdict: REPRODUCED (out-of-bounds read past the 1024-byte csrrom)

`crom_parse_text()` (`sys/bus/firewire/fwcrom.c:187-225`) bounds-checks the
text leaf with:

```
fwcrom.c:207   if ((vm_offset_t)textleaf + textleaf->crc_len > CROM_END(cc)) ...
```

but `crc_len` counts **32-bit quadlets, not bytes** — the loop immediately
below indexes `textleaf->text[i]` as `u_int32_t` with `qlen = crc_len - 2`
(`:215-219`).  The check is therefore ~4× too lax: a text leaf whose
`crc_len` fits the *byte* bound still reads `text[i]` quadlets far past the
csrrom buffer.

Concrete: root dir at quad 5 (`info_len=4`), text leaf at quad 250,
`crc_len = 20`.
- byte-check (`:207`): `textleaf(1000) + 20 = 1020 <= 1023` → **PASSES**
- quad loop (`:218`): `qlen = 18`, reads `text[0..17]` = quads 253..270 →
  **quads 256..270 are out-of-bounds** (15 quads = 60 bytes OOB).

## Reproduction (no FireWire hardware needed)

Same harness as DF-1084 (links the real `-DTEST` parser):

```
crom_parse_text output bytes (hex): 42424242 ... (60+ bytes of 0x42 OOB poison)
[+] DF-1086 CONFIRMED: crom_parse_text copied 60+ bytes of OOB memory via the
    byte-vs-quad crc_len check bug at fwcrom.c:207.
```

In the kernel these OOB bytes are adjacent `fw_device`/ConfigROM fields
exposed to userland via `sdev->vendor` → SCSI INQUIRY (`sbp.c:1527`), i.e. an
info leak of kernel heap values to any CAM inquiry.

## Reachability

Same as DF-1084: FireWire in GENERIC (DF-1083), parser exercised at device
attach; no FW controller on the audit guest, so demonstrated against the real
parser code.  Impact ceiling: kernel info-leak / panic.

## Fix (validated at harness level)

`fix.diff` scales the bound by `sizeof(u_int32_t)`:
`if ((vm_offset_t)textleaf + (size_t)textleaf->crc_len * sizeof(u_int32_t) > CROM_END(cc))`.
Re-linked harness returns the `"(null)"` fallback with **0** OOB bytes copied.