# DF-1084 — crom_init_context trusts attacker-controlled info_len (OOB read)

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

`crom_init_context()` (`sys/bus/firewire/fwcrom.c:62-94`) reads
`hdr->info_len` — an 8-bit field taken directly from device-supplied
ConfigROM (`fwcrom.c:67`) — and uses it to advance the data pointer past the
bus-info block with **no upper-bound check**:

```
fwcrom.c:84    p += 1 + hdr->info_len;
```

`MAX_ROM` (`:59`) is a hardcoded 1004 and `CROM_END` (`:60`) is computed from
the *advanced* `stack[0].dir`, not the buffer origin, so a malicious
`info_len` pushes the root-directory pointer out of the buffer.  With
`info_len = 255`, `p` advances by `1 + 255 = 256` quads = **1024 bytes**, i.e.
exactly past the 1024-byte (256-quad) csrrom buffer.  The very next line
(`fwcrom.c:87`, `((struct csrdirectory *)p)->crc_len`) already dereferences
out-of-bounds memory.

## Reproduction (no FireWire hardware needed)

`fwcrom.c` ships a userland `-DTEST` mode, so the harness links against the
**real kernel parser** (its demo `main()` renamed away) and feeds it a crafted
ROM backed by a poisoned region, with only the first 256 quads treated as the
logical csrrom:

```
hdr->info_len        = 255
logical csrrom range = quads [0 .. 256)  (1024 bytes)
&rom[256] (OOB start)= 0x403660
cc.depth             = 0
cc.stack[0].dir      = 0x403660          <- root-directory pointer
crom_get()           = 0x403664          <- derefs OOB memory
  OOB reg->crc_len   = 0x00004242        <- read from quad 256 (OOB)
[+] DF-1084 CONFIRMED: root-directory pointer 0x403660 is at quad 256, PAST
    the 1024-byte csrrom end.
```

The parser proceeds (`depth=0`) and `crom_get()`/`crom_parse_text()` then
operate entirely on OOB memory — in the kernel this is the adjacent
`fw_device` fields (`firewirereg.h:44-62`) holding kernel heap pointers,
yielding an info leak / panic.

## Reachability

FireWire is compiled into the GENERIC kernel (per DF-1083) and the parser is
exercised at device attach via `sbp_alloc_lun`/`crom_parse_text`.  The audit
guest has no FireWire controller, so the live device path is not triggerable
here; the bug is demonstrated against the actual parser code instead, which is
the authoritative reproduction for this class.  Impact ceiling: kernel
info-leak of adjacent `fw_device` pointers (KASLR-bypass) or panic.

## Fix (validated at harness level)

`fix.diff` adds `if (hdr->info_len > 254) { reject }` before the pointer
advance.  Re-linking the harness against the patched parser yields
`crom_init_context: info_len 255 too large`, `cc.depth = -1`,
`cc.stack[0].dir = NULL` — the OOB read is eliminated.