# DF-2288 — OOB heap write/read in fw_bus_explore_callback (CSR ROM parser)

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

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

The DragonFlyBSD audit guest is a QEMU/KVM VM with **no FireWire (IEEE 1394)
hardware whatsoever**. Confirmed at audit time:

```
$ pciconf -l          # no fwohci / firewire bridge present
hostb0@pci0:0:0:0:   class=0x060000 ...  (i440fx hostbridge)
isab1@pci0:0:1:0:    class=0x060100 ...  (PIIX3 ISA bridge)
atapci0@pci0:0:1:1:  class=0x010180 ...  (PIIX3 IDE)
vgapci0@pci0:0:2:0:  class=0x030000 ...  (Bochs/QEMU std VGA)
virtio_pci0/1 ...                           (net + blk)
$ ls /dev/fw*         # /dev/fw*: No such file or directory
$ ifconfig -l         # vtnet0 lo0  (no fwip/fwe firewire net iface)
```

There is no FireWire controller (`fwohci`) attached, no `/dev/fw*` character
device, and no firewire network interface. The vulnerable path
`fw_bus_explore_callback()` runs **only** in the FireWire stack's bus-enumeration
state machine, which is driven by `fwohci` interrupt delivery from real 1394
hardware during bus exploration. With no `fwohci` device and no `/dev/fw*` node
reachable by the unprivileged `maxx` user, the callback can never be driven by
attacker-controlled Config-ROM responses on this guest.

The `hw.firewire.*` sysctl nodes exist only because the firewire subsystem is
compiled into the kernel; they are inert defaults — `pciconf -l` proves no
controller is probed/attached.

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

The claim is accurate. The write happens BEFORE the bounds check, the bounds
check is an off-by-one (`>` instead of `>=`), and the directory-entry jump
advances `ongoaddr` with no bounds check at all.

`fw_device` carries `u_int32_t csrrom[CSRROMSIZE/4]` = `csrrom[0x400/4]` =
`csrrom[256]` (sys/bus/firewire/firewirereg.h:51-54; `CSRROMOFF = CSRROMSIZE =
0x400`). Valid offsets are `csrrom[0..255]`.

1. **Write-before-check.** `firewire.c:1500`:
   ```c
   fc->ongodev->csrrom[(fc->ongoaddr - CSRROMOFF)/4] = ntohl(rfp->mode.rresq.data);
   ```
   stores the attacker-controlled (peer-supplied) 4-byte Config-ROM quadlet into
   `csrrom[]` indexed by `ongoaddr` **unconditionally**, then the only bounds
   check appears ~58 lines later at `firewire.c:1558`:
   ```c
   if((fc->ongoaddr - CSRROMOFF) > CSRROMSIZE){   // > should be >=
       goto nextnode;
   }
   ```
   So `ongoaddr == CSRROMOFF + CSRROMSIZE` (index 256, one past end) is written
   first and only then (incorrectly) allowed through.

2. **Unbounded directory-entry jump.** `firewire.c:1514-1524`:
   when the parser sees a Unit-/Directory-entry key (`0x81`/`0xd1`) it does
   ```c
   fc->ongoaddr += csrreg->val * 4;     // firewire.c:1520
   ```
   `csrreg->val` is a 24-bit field taken directly from the (malicious) ROM with
   **no upper bound**. A crafted ROM can therefore advance `ongoaddr` far past
   `CSRROMSIZE`, and the next callback iteration writes attacker bytes at
   `csrrom[(ongoaddr-CSRROMOFF)/4]` deep past the end of the `fw_device` heap
   object. On amd64 `csrrom[0x101]/[0x102]` alias the low/high halves of the
   following `fc` pointer (`firewirereg.h` fw_device layout), yielding a
   controlled kernel-pointer dereference in `fwmem_xfer_req`.

3. **Info-leak path.** `rommax` is set to `ongoaddr` with no upper bound
   (`firewire.c:1501-1503`), and the General-Config-ROM copyout (`FW_GCROM`)
   later copies `csrrom[]` out to userspace, leaking post-buffer kernel heap.

Impact (on real FireWire hardware, absent here): kernel heap write of
attacker-controlled value at an attacker-influenced offset, plus a kernel-heap
info-leak via FW_GCROM. Trigger: any device physically on the IEEE 1394 bus; no
authentication.

## Exploit chain status

Not pursuable on this guest — the primitive is gated behind absent FireWire
hardware (valid Phase-6 hard blocker: "vulnerable code path dead/unreachable at
runtime on this guest AND no harness can exercise it" because it requires a live
1394 peer responding with crafted ROM quadlets). The bug is a real, write-capable
heap-corruption primitive on hardware that owns a 1394 controller; the
defense-in-depth fix below closes it.

## PoC changes

None. No PoC source was authored or runnable: the `/dev/fw*` device does not
exist and the `fwohci` controller is absent, so neither a userspace ioctl
reproducer (which would need an attached FireWire peer's responses) nor a kernel
harness can drive `fw_bus_explore_callback` on this guest. The README claim was
verified purely by source trace.

## Recommended fix

Bound `ongoaddr` *before* the write and fix the off-by-one. See `fix.diff`
(supersedes finding proposal by hardening the directory-jump path the finding
markdown focuses on, plus the `>`→`>=` correction).