DF-2289 — Off-by-one stack overflow in crom_next depth guard (fwcrom.c)

Verdict: NOT REPRODUCED (HW-gated); REAL BUG IN SOURCE (defense-in-depth fix warranted)

Hardware gate (why the PoC cannot run on this guest)

crom_next() parses IEEE 1394 Configuration ROM and is reached via the FireWire stack (e.g. crom_init_context / crom_search_key invoked while enumerating remote nodes). The audit QEMU/KVM guest has no FireWire controller and no /dev/fw* device:

$ pciconf -l | grep -iE "fwohci|firewire"   # (no output)
$ ls /dev/fw*                                # /dev/fw*: No such file or directory
$ ifconfig -l                                # vtnet0 lo0

Without an fwohci controller and a live 1394 peer there is no path to feed a crafted Config-ROM into crom_next. The unprivileged maxx user cannot open /dev/fw* (it does not exist), so no ioctl or userspace path reaches the parser on this guest.

Source trace — the bug is REAL (sys/bus/firewire/fwcrom.c)

Layout (iec13213.h:200-209):

#define CROM_MAX_DEPTH  10
struct crom_ptr   { struct csrdirectory *dir; int index; };
struct crom_context { int depth; struct crom_ptr stack[CROM_MAX_DEPTH]; };
                                       /* stack[0..9], 10 elements */

crom_next() (fwcrom.c:106-143):

reg = crom_get(cc);                          /* cc->stack[cc->depth] */
if ((reg->key & CSRTYPE_MASK) == CSRTYPE_D) {
    if (cc->depth >= CROM_MAX_DEPTH) {       /* line 115: checks BEFORE incr */
        kprintf("crom_next: too deep\n");
        goto again;
    }
    cc->depth ++;                            /* line 119: now depth == 10 */
    ptr = &cc->stack[cc->depth];             /* line 121: &stack[10] = ONE PAST END */
    ptr->dir  = (struct csrdirectory *)(reg + reg->val);  /* 8-byte attacker ptr */
    ptr->index = 0;                          /* + 4 bytes */
    goto check;
}

The guard at line 115 fires only when depth >= 10, but the array's last legal index is 9. So when the parser enters crom_next at depth == 9 (10th level of nesting already reached) and the current entry is a directory (CSRTYPE_D), the guard 9 >= 10 is false, execution proceeds to cc->depth++ (now 10) and ptr = &cc->stack[10] — one past the end of the 10-element array. ptr->dir (an 8-byte attacker-controlled pointer derived from reg->val) and ptr->index (4 bytes) are then written, a 16-byte stack overflow into whatever follows crom_context.stack[] (saved registers / adjacent locals). The correct guard is cc->depth >= CROM_MAX_DEPTH - 1 (i.e. >= 9), or move the increment-before-check.

After the overflow, goto check dereferences ptr->dir->crc_len (fwcrom.c:130) — an attacker-controlled pointer read → kernel info-leak or panic.

Trigger: a malicious FireWire device whose Config ROM contains a chain of 10 nested CSRTYPE_D directory entries. No authentication; physical bus access.

Exploit chain status

Not pursuable — primitive is behind absent FireWire hardware (valid Phase-6 hard blocker: dead path at runtime + no harness can drive it on this guest without a live 1394 peer). The bug is a real 16-byte controlled stack overflow on FireWire-equipped hardware.

PoC changes

None. No PoC runnable: /dev/fw* absent, fwohci controller absent. Verified by source trace only.

Recommended fix

Tighten the depth guard so the increment never reaches the sentinel index. See fix.diff (matches the finding proposal's intent — guard against depth >= CROM_MAX_DEPTH - 1).