# DF-2708 — DMSG wire msgid discloses the kernel heap address of every
# kernel-initiated transaction state to the cluster peer

## What was verified (stock INVARIANTS kernel #0, guest dfbsd)

`kdmsg_msg_alloc()` assigns each kernel-initiated transaction state
`state->msgid = (uint64_t)(uintptr_t)state` (sys/kern/kern_dmsg.c:1804)
and transmits it as `msg->any.head.msgid` (:1833) — so every
kernel-initiated transaction hands the peer the kmalloc address of its
`kdmsg_state_t` (allocated :1796 from the HAMMER2-msg zone, ~160-byte
class). The kernel's auto-initiated LNK_CONN on every cluster reconnect
(`kdmsg_iocom_autoinitiate()`, kern_dmsg.c:184-191) is the always-present
instance; kernel-initiated LNK_SPANs (hammer2_update_spans) leak one
pointer each.

PoC: `df2707_trigger leak` (source shared with the DF-2707 pack) mounts
a hammer2 volume with `cluster_fd` = our socketpair end, reads the
auto-LNK_CONN, and cross-checks against the console print
`volconf update %p` of the very same object (`hmp->iocom.conn_state`,
hammer2_iocom.c:376, populated via the REMOTE_ADD ioctl).

Result (exact values, one run):

```
trigger stdout: AUTO_CONN cmd=80001106 msgid=0xfffff8011741eae0
dmesg:          volconf update 0xfffff8011741eae0        <-- identical
```

Repeat runs (3 mounts across this session) always produced a fresh
`0xfffff80xxxxxxxxx` direct-map kernel heap pointer.

## Impact

Any cluster peer — the userland hammer2 service daemon's remote
connection, a malicious/compromised cluster node, or a network MITM
(receive-side CRCs are not verified, LNK_AUTH unimplemented) — learns
kernel heap addresses without any log access. Defeats heap-layout
randomization and primes pointer forgery for exploitation of memory
corruption in the same subsystem (e.g. DF-2707's stale-rbnode writes).
Not directly reachable by an unprivileged local user (mount/REMOTE_ADD
require root; the leak goes to the *peer*, not to dmesg).

## Build & run

```
scp -F dfbsd-qemu/config findings/poc/DF-2707/df2707_trigger.c \
                      findings/poc/DF-2707/run_df2707.sh dfbsd:/root/poc/df2707/
dfbsd-qemu/vm.sh run_root 'sh /root/poc/df2707/run_df2707.sh leak'
# compare: AUTO_CONN msgid  ==  dmesg 'volconf update' value
```

## Fix direction

Use an opaque per-iocom 64-bit counter (protected by msglk) for
kernel-initiated msgids instead of the state pointer, matching the
msg_seq allocator already present for `salt` (kern_dmsg.c:2002-2003).
Peer-initiated states already use peer-chosen msgids, so no protocol
change is needed. (`msgid` uniqueness within statewr_tree is all the
protocol requires, kern_dmsg.c:1808-1809.)