DragonFlyBSD Kernel Audit
1086 / run.log
← back to finding ↓ download raw
=== 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