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.