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.