# 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.