# DF-2614 — hammer2 iocom debug kprintf's (heap pointer + peer-driven flood)

## What was verified (stock kernel #0, then fix kernel)

1. **Heap-pointer leak (hammer2_iocom.c:376)** — reproduced:
   mount a hammer2 volume with `cluster_fd` = our socketpair end
   (the mount program's documented cluster-controller hook,
   hammer2_vfsops.c:1350-1357), then issue `HAMMER2IOC_REMOTE_ADD`
   (hammer2_ioctl.c:308 -> hammer2_volconf_update) as root:
   `dmesg` gains `volconf update 0xfffff801177797c0` — the live
   kmalloc'd `kdmsg_state_t` (`conn_state`, kern_dmsg.c:189-190).
   A second line appears from the unmount teardown (simulated CONN
   failure -> hammer2_autodmsg -> volconf_update at hammer2_iocom.c:231).
   **Readable by an unprivileged user**: `run_user 'dmesg | grep "volconf
   update"'` returns the pointer (see unpriv_read.log); the lines also
   land in /var/log/messages.  Bonus context: `HAMMER2: VOLDATA DUMP` /
   `INITIATE SPANs` (:220/:236) fire even at ordinary root-fs boot and
   at unmount teardown, and vfsops prints more ungated heap pointers
   (`hammer2_mount: hmp=%p pmp=%p`) adjacent to this finding.

2. **Peer-driven console/msgbuf flood (hammer2_iocom.c:135)** —
   reproduced: from the peer end of the cluster socket, send 1000
   one-way 64-byte LNK_PAD frames (magic 0x4832, cmd 0x1; the kernel's
   receive path validates only magic+size, kern_dmsg.c:343-352) -> the
   kernel emits exactly 1000 `RCVMSG 00000001` kprintf lines — one per
   message, no flag, no rate limit — to the console lock and the msgbuf
   ring.  A remote cluster node (the threat position in the finding)
   reaches the same kernel path through the userland hammer2 service
   daemon's relayed connection.

## Files
- `df2614_trigger.c`  trigger (mount with cluster_fd, REMOTE_ADD ioctl,
                       PAD-frame flood, unmount)
- `run_df2614.sh`     guest-side orchestration (image, newfs, build, run,
                       dmesg deltas)
- `build.sh`/`run.sh` host-side wrappers
- `run.log`           FULL untrimmed stock-kernel run (set -x), incl.
                      pointer values and counts
- `trigger.stock.out` trigger stdout, stock kernel
- `run.fix.log`       same trigger on the fix kernel (0/0 deltas)
- `unpriv_read.log`   live capture: unprivileged user reads the pointer
- `fix.diff`          the fix (drop %p print, gate the rest behind
                      hammer2_debug & 0x0100)
- `build.log`         cc output

## Build & run (from the repo root)
```
scp -F dfbsd-qemu/config findings/poc/DF-2614/df2614_trigger.c findings/poc/DF-2614/run_df2614.sh dfbsd:/root/poc/df2614/
dfbsd-qemu/vm.sh run_root 'sh /root/poc/df2614/run_df2614.sh'
```
Stock kernel: `DELTA_volconf=2`, `DELTA_rcvmsg=1000`.
Fix kernel:   `DELTA_volconf=0`, `DELTA_rcvmsg=0`, operations unchanged.