DF-0018 — PoC

Duplicate DELETE for the same DMSG msgid trips the KKASSERT at kern_dmsg.c:1076 and panics an INVARIANTS (default GENERIC) DragonFly kernel.

The bug

kdmsg_state_msgrx() (in sys/kern/kern_dmsg.c) unconditionally asserts on a received DELETE:

KKASSERT((state->rxcmd & DMSGF_DELETE) == 0);   /* kern_dmsg.c:1076 */

A peer sends CREATE for msgid N, then two DELETEs for msgid N back-to-back. The reader thread processes them sequentially:

1. CREATE (case DMSGF_CREATE, :851): allocates a new state, sets state->rxcmd = msg->any.head.cmd & ~DMSGF_DELETE (so rxcmd has DMSGF_CREATE, no DMSGF_DELETE), RB_INSERTs into staterd_tree (:916).
2. DELETE-1 (case DMSGF_DELETE, :920): state found via RB_FIND; the early-out checks at :925 (state==state0) and :943 ((rxcmd & DMSGF_CREATE) == 0) do NOT match (CREATE still set), so error=0. At :1075, the DELETE post-block runs: :1077 state->rxcmd |= DMSGF_DELETE; :1078 if (state->txcmd & DMSGF_DELETE) is FALSE (the writer has not yet transmitted our REPLY|DELETE), so RB_REMOVE is NOT taken -- the state stays in the tree.
3. DELETE-2: RB_FIND finds the same state still in staterd_tree; same early-out checks; error=0; reaches :1075; :1076 KKASSERT((state->rxcmd & DMSGF_DELETE) == 0) -- rxcmd now HAS DMSGF_DELETE (set in step 2) -- assertion fires -> kernel panic.

The race window (between the reader finishing DELETE-1's cleanuprx and the writer transmitting the REPLY|DELETE that would set txcmd |= DMSGF_DELETE and remove the state) is won trivially by sending both DELETEs back-to-back, because the reader is single-threaded per iocom and the writer must dequeue + fp_write the reply.

KKASSERT is #ifdef INVARIANTS (sys/sys/systm.h:94-122); the default X86_64_GENERIC ships options INVARIANTS, so the panic occurs on default kernels. On a non-INVARIANTS kernel the assertion compiles to a no-op and the duplicate DELETE is absorbed benignly (rxcmd |= DMSGF_DELETE is idempotent; the RB_REMOVE branch is not taken because txcmd lacks DELETE).

Severity / impact

Low. INVARIANTS-kernel DoS only; no integrity/confidentiality impact, no escalation path (panic aborts the kernel before any further primitive can be derived). Same class as DF-0001.

Threat model & reachability

The bug is in the kdmsg protocol state machine, exercised by every received DELETE. Reachable by any DMSG peer:

• the HAMMER2 cluster relay daemon over the cluster network (the network vector -- matches the finding's CVSS AV:N),
• a disk cluster peer via DIOCRECLUSTER on a disk device node (requires operator/wheel privilege on the device node), or
• the xdisk virtual block device peer.

The PoC needs an "iocom to talk to". On this guest there is no cluster-link to inject bytes into from an unprivileged user, so this folder ships two equivalent demonstrations:

• kdmsg_dupdelete.c (original reviewer PoC) -- writes raw dmsg bytes to a fd passed as argv[1]. Use when you already have a connected DMSG socket end (e.g. via a HAMMER2 relay). Untouched.
• trigger.c -- a self-contained userland trigger that gets a kernel iocom via socketpair(2) + DIOCRECLUSTER on a disk device node. Requires operator/wheel privilege (matches the disk-cluster threat model). NOTE: on this guest the DIOCRECLUSTER path exhibited an environmental hang unrelated to this bug (the disk-iocom autoinitiate path deadlocks against the socketpair); use harness.c for a deterministic reproduction.
• harness.c + Makefile -- the deterministic in-kernel harness that was used to validate this finding. It creates a private kdmsg_iocom over an in-kernel kern_pipe(2), with no AUTO* flags (so no autoinitiate complications), and writes the three header bytes (CREATE, DELETE, DELETE for msgid=42) into the pipe's write end. The kernel's kdmsg_iocom_thread_rd reader drains them in order and panics at kern_dmsg.c:1076. Loading it requires root (kldload), which models the cluster-peer privilege position the bug requires.

Build & run

Inside the guest, as root:

cd /tmp/df18_harness     # or wherever you copied harness.c + Makefile
./build.sh               # -> df18_harness.ko
./run.sh                 # kldload ./df18_harness.ko

Expected on the unpatched kernel (INVARIANTS on, default GENERIC)

panic: assertion "(state->rxcmd & DMSGF_DELETE) == 0" failed in kdmsg_state_msgrx at /usr/src/sys/kern/kern_dmsg.c:1076
cpuid = 5
Trace beginning at frame 0xfffff80117f5b940
kdmsg_msg_receive_handling() at kdmsg_msg_receive_handling+0xb39 0xffffffff80636d39
kdmsg_iocom_thread_rd() at kdmsg_iocom_thread_rd+0x98 0xffffffff806380e8
Debugger("panic")
Stopped at Debugger+0x7c: movb $0,0xbdaf09(%rip)
db>

(Full panic signature in panic.txt; full boot-log excerpt in run.log.)

Expected on the fixed kernel

df18: iocom up; writing CREATE+2xDELETE for msgid=42
kdmsg: msgrx: duplicate DELETE
kdmsg: msgrx: state=0xfffff80117554a40 error 37
df18: harness completed without panic ...

No panic, no wedge; the duplicate DELETE is discarded as EALREADY (errno 37) via the new guard added by fix.diff. (Full excerpt in fix_run.log.)

Fix

fix.diff -- inserts a benign-discard guard before the error = 0; fall- through of the DELETE case, mirroring the existing EALREADY handling for ABORT+DELETE races (:926-930, :944-947). When state->rxcmd already has DMSGF_DELETE, the duplicate DELETE is logged, error is set to EALREADY, and the switch breaks -- never reaching the KKASSERT. This matches (and is functionally identical to) the ## Recommended fix block in findings/DF-0018-*.md.

Validated: the patched #1 kernel handles the same input that panicked #0 without incident (fix_run.log).

DF-0018 — VERDICT

REPRODUCED. Duplicate DELETE for the same DMSG msgid panics the default X86_64_GENERIC (INVARIANTS-on) DragonFly kernel via the KKASSERT at sys/kern/kern_dmsg.c:1076. Fix validated: a single-fix kernel that adds a benign-discard guard before the assertion handles the same input gracefully.

Verdict

REPRODUCED + FIX VALIDATED.

Mechanism (line-by-line)

The bug is in kdmsg_state_msgrx() (sys/kern/kern_dmsg.c), the receive-side state machine driven by kdmsg_iocom_thread_rd. The reader is single-threaded per iocom; the writer (kdmsg_iocom_thread_wr) transmits replies asynchronously.

1. CREATE for msgid=N -- case DMSGF_CREATE at :851 allocates a new state (:898), sets state->rxcmd = msg->any.head.cmd & ~DMSGF_DELETE (:912, so rxcmd has DMSGF_CREATE but not DMSGF_DELETE), RB_INSERTs into iocom->staterd_tree (:916), and returns error=0 (:918).
2. DELETE-1 for msgid=N -- case DMSGF_DELETE at :920. RB_FIND finds the state. The two early-out checks both fail: - :925 state == &iocom->state0 -- false (state is real); - :943 (state->rxcmd & DMSGF_CREATE) == 0 -- false (CREATE still set). So error=0 (:955). Post-callback, the DELETE post-block at :1075 runs: :1077 state->rxcmd |= DMSGF_DELETE; :1078 if (state->txcmd & DMSGF_DELETE) is FALSE (the writer hasn't transmitted our REPLY|DELETE yet), so the RB_REMOVE at :1088 is NOT taken. The state stays in staterd_tree with rxcmd now carrying both DMSGF_CREATE and DMSGF_DELETE.
3. DELETE-2 for msgid=N -- RB_FIND still finds the state (it was never removed). Same two early-out checks; both still fail; error=0. Reaches :1075. :1076 KKASSERT((state->rxcmd & DMSGF_DELETE) == 0) -- rxcmd now HAS DMSGF_DELETE -- assertion fires -> kernel panic.

The race window is between the reader finishing DELETE-1's cleanuprx and the writer transmitting the REPLY|DELETE; sending both DELETEs back-to-back wins it trivially (the reader processes them in sequence, the writer has to dequeue + fp_write its reply).

KKASSERT is #ifdef INVARIANTS (sys/sys/systm.h:94-122); the default X86_64_GENERIC ships options INVARIANTS, so the panic occurs on the default kernel. On a non-INVARIANTS kernel the assertion compiles to a no-op and the duplicate DELETE is absorbed benignly -- so this is an INVARIANTS-only DoS, same class as DF-0001.

Reproduction

The harness (harness.c + Makefile) builds a kernel module (df18_harness.ko) that creates a private kdmsg_iocom over an in-kernel kern_pipe(2) (no AUTO* flags, so no autoinitiate complications) and writes three raw dmsg headers into the pipe's write end:

1. CREATE msgid=42 (LNK_PAD | DMSGF_CREATE = 0x80000001)
2. DELETE msgid=42 (LNK_PAD | DMSGF_DELETE = 0x40000001)
3. DELETE msgid=42 (LNK_PAD | DMSGF_DELETE = 0x40000001)

The kernel's kdmsg_iocom_thread_rd drains them in order and panics on the third. kldload-ing the module reproduces deterministically (no timing race needed -- the writer thread never gets to run between the two DELETEs because the module writes them all before yielding).

Panic signature (unpatched #0)

panic: assertion "(state->rxcmd & DMSGF_DELETE) == 0" failed in kdmsg_state_msgrx at /usr/src/sys/kern/kern_dmsg.c:1076
cpuid = 5
kdmsg_msg_receive_handling() at kdmsg_msg_receive_handling+0xb39 0xffffffff80636d39
kdmsg_iocom_thread_rd() at kdmsg_iocom_thread_rd+0x98 0xffffffff806380e8
Stopped at Debugger+0x7c: movb $0,0xbdaf09(%rip)
db>

Call chain: reader thread -> kdmsg_msg_receive_handling -> kdmsg_state_msgrx -> KKASSERT at :1076. Exactly the path the finding cites.

Why a harness (vs. a userland-only trigger)

The threat model is "a DMSG peer" -- reachable via the HAMMER2 cluster relay daemon (network vector, matches CVSS AV:N), via DIOCRECLUSTER on a disk device node (requires operator/wheel privilege on the device), or via the xdisk virtual block device. None of these is reachable from an unprivileged user on this guest (maxx uid 1001 is not in operator). The realistic peer position is therefore a privileged one, which the kldload-ed harness models directly: it exercises the exact receive path that any peer-driven bytes would, without the DIOCRECLUSTER autoinitiate-thread / socketpair-buffer deadlock that the userland socketpair + DIOCRECLUSTER trigger hits on this particular guest (environmental, unrelated to this bug).

This is a code-level harness in the sense the procedure allows for too-narrow-to-reach-from-unprivileged findings; the bug it triggers is the same KKASSERT any peer-driven bytes would trip.

Impact / ceiling

Low. INVARIANTS-only kernel DoS (panic). No memory corruption, no info leak, no integrity impact, no escalation primitive -- the assertion aborts the kernel before any further state manipulation. Same class as DF-0001. CVSS AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H matches (the network vector is unauthenticated from a packet standpoint; AC:H reflects the "must be an established cluster peer" precondition).

No escalation chain applicable -- this is a pure DoS.

Exploit chain

None (non-corruption class: pure DoS via INVARIANTS assertion).

Fix

fix.diff inserts a benign-discard guard immediately before the error = 0; fall-through of the DELETE case (kern_dmsg.c:955), after the existing "msgid reused" check at :943-954:

/*
 * A duplicate DELETE can race our reply transmission ...
 */
if (state->rxcmd & DMSGF_DELETE) {
    kdio_printf(iocom, 1, "%s\n", "msgrx: duplicate DELETE");
    error = EALREADY;
    break;
}

This mirrors the existing EALREADY handling for the ABORT+DELETE races at :926-930 and :944-947. The duplicate DELETE is logged, error is set to EALREADY, and kdmsg_msg_receive_handling (:689-690) treats EALREADY as a benign discard. Functionally identical to the finding's ## Recommended fix proposal.

Fix validation (Phase 8)

• Baseline (#0, unpatched): harness panics with the assertion signature above. (run.log, panic.txt.)
• Patched (#1, single-fix via make installkernel): kern.version = DragonFly 6.5-DEVELOPMENT #1: Sun Jul 12 14:16:09 UTC 2026 sha256(/boot/kernel/kernel) = f25163731649235e8032546312974e93ef8fa3eab1b25031749ad511b4e30d29 Same harness input -> NO panic; prints kdmsg: msgrx: duplicate DELETE and kdmsg: msgrx: state=0xffff... error 37, then df18: harness completed without panic. (fix_run.log.)
• Before/after contrast: panic-vs-EALREADY on identical input; the fix closes the bug.

PoC changes

• Added harness.c + Makefile -- the deterministic in-kernel harness used to reproduce the panic. The original reviewer PoC (kdmsg_dupdelete.c) is unchanged.
• Added trigger.c -- a self-contained userland trigger via socketpair
• DIOCRECLUSTER; documented its environmental hang on this guest (unrelated to the bug).
• Added fix.diff, build.sh, run.sh, panic.txt, build.log, run.log, fix_build.log, fix_run.log, env.txt, VERDICT.md, manifest.json.
• Updated README.md to describe the harness path and the fix.