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.

DF-2614 VERDICT

Reproduced: YES (stock kernel) — kernel heap pointer to msgbuf (world-readable) + ungated per-message console print; fix validated on rebuilt kernel.

How (stock kernel #0, unmodified source, 2026-08-29 ~10:26-10:30 UTC)

Trigger program df2614_trigger.c: 1. socketpair(AF_UNIX, SOCK_STREAM); mount("hammer2", "/mnt/h2poc", 0, &info) with info.cluster_fd = sv[0] — the documented cluster-controller hook (hammer2_vfsops.c:1350-1357 -> hammer2_cluster_reconnect -> kdmsg_iocom_reconnect kern_dmsg.c:162-165 -> autoinitiate kern_dmsg.c:184-191 sets iocom->conn_state = msg->state, a fresh kmalloc(sizeof(kdmsg_state_t), M_HAMMER2)-style allocation). 2. ioctl(fd, HAMMER2IOC_REMOTE_ADD, ...) on a file of the mounted volume -> hammer2_ioctl_remote_add (hammer2_ioctl.c:308) -> hammer2_volconf_update -> hammer2_iocom.c:376 kprintf("volconf update %p\n", hmp->iocom.conn_state). Observed: volconf update 0xfffff801177797c0 (twice: ioctl + unmount-teardown path via hammer2_autodmsg). 3. Peer-side flood: 1000 one-way LNK_PAD frames (64-byte header, magic=0x4832, cmd=DMSG_LNK_PAD=0x1; no CRC is verified on receive — kern_dmsg.c:339-352) -> each reaches hammer2_rcvdmsg through kdmsg_autorxmsg's default branch (kern_dmsg.c:1220) -> hammer2_iocom.c:135 kprintf("RCVMSG %08x\n", msg->tcmd). Observed: exactly 1000 RCVMSG 00000001 lines in the msgbuf/console.

Unprivileged exposure (live, user maxx via vm.sh run_user): dmesg | grep "volconf update" -> the pointer; the lines are also in /var/log/messages. The msgbuf is world-readable on this system.

Additional ungated prints confirmed live (same class, adjacent sites, beyond the filed lines — for the record): HAMMER2: VOLDATA DUMP / HAMMER2: INITIATE SPANs (:220/:236) fire at ordinary root-fs boot and unmount teardown; hammer2_mount: hmp=%p pmp=%p (vfsops) prints two more heap pointers per mount.

Reachability honesty: triggering the print locally requires root (mount/ioctl). The filed threat positions stand: (1) any local user READS the pointer after a root cluster mount/remote-add (proven: unpriv read); (2) a cluster peer (unauthenticated remote node, or any process holding the daemon's socket) drives the per-message print at wire rate (proven: 1000/1000 with the peer socket). The finding's Low severity is confirmed; the pointer-leak half is KASLR-support material on KASLR-enabled kernels (this guest has none) — impact class: leak.

Fix validation (kernel #3/#5, X86_64_GENERIC rebuilt via nativekernel)

fix.diff removes the %p print entirely, drops the RCVMSG print, and gates the four remaining message-path prints behind hammer2_debug & 0x0100 (the codebase's own pattern, cf. hammer2_iocom.c:258). After rebuild + reboot, the identical trigger: DELTA_volconf=0, DELTA_rcvmsg=0, REMOTE_ADD_OK copyid=1, FLOOD_SENT=1000 (frames still accepted+ignored per protocol), UNMOUNT_OK — no functional regression, all debug output gone.

verdict

status=reproduced (impact=leak), fix validated (fixed). Severity Low is right: root-gated trigger, unprivileged read of one heap pointer, and a peer-driven console/log flood on clustered systems.