1084 / run.log
=== DF-1084: crom_init_context info_len overflow ===
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
cc.stack[0].index = 0
crom_get() = 0x403664 (derefs OOB memory)
OOB reg->crc_len = 0x00004242 (read from quad 256)
[+] DF-1084 CONFIRMED: root-directory pointer 0x403660 is at quad 256, PAST the 1024-byte csrrom end (quad 256).
crom_init_context advanced `p` by 1+info_len=256 quads with no upper-bound check (fwcrom.c:84); the crc_len read at fwcrom.c:87 already derefs OOB memory.
=== DF-1086: crom_parse_text crc_len bytes-vs-quads ===
root dir @ quad 5, text-leaf @ quad 250, crc_len=20
CROM_END = byte 1023 (quad 255); leaf byte-check 1000+20=1020 <=1023 PASSES
but quad loop reads text[0..17] = quads 253..270 -> quads 256..270 are OOB
crom_parse_text output bytes (hex, first 96):
42424242424242424242424242424242424242424242424242424242424242424242424242424242424242424242424242424242424242424242424242424242424242424242424200d8dfffff7f000000000000000000006036400000000000
[+] DF-1086 CONFIRMED: crom_parse_text copied 60+ bytes of OOB memory (0x42 poison from quads 256+) into the output buffer via the byte-vs-quad crc_len check bug at fwcrom.c:207.
RC=0