VERDICT — DF-3397: analysis-only (module does not build on DragonFly)

Root cause

netmap_mem_rings_create() initializes the rx rings' buffer-size field with a 4-byte write:

sys/net/netmap/netmap_mem2.c:974:
    *(int *)(uintptr_t)&ring->nr_buf_size =
        NETMAP_BDG_BUF_SIZE(na->nm_mem);

but struct netmap_ring.nr_buf_size is const uint16_t (sys/net/netmap/netmap.h:225), immediately followed by uint16_t flags (netmap.h:226). The 4-byte store therefore overwrites the adjacent flags field with the high 16 bits of the buffer size. The tx-ring initialization 30 lines earlier does it correctly: *(uint16_t *)(uintptr_t)&ring->nr_buf_size (netmap_mem2.c:945).

Consequence (latent)

With default pool sizes (buf objsize 2048) the high half of the size is 0, so flags is re-zeroed on an already-zeroed allocation — benign by luck. With a large buf size (pool is configurable up to objmaxsize 65536 via dev.netmap.buf_size; NETMAP_BDG_BUF_SIZE rounds to the pool _objsize), the high half becomes 1 and flags is silently set — userspace then sees NR_TIMESTAMP/NR_FORWARD/NR_RX_TSTMP style flag bits it never requested, changing ring semantics (e.g. timestamp writes into slots, buffer forwarding) on rx rings only. Latent: the module does not build on this tree (netmap_build.log; same platform fact as DF-3396).

Fix status (batch validation)

Applied with the 36 sibling fix.diffs of this batch in findings/poc/_batch41/all_fixes.patch; single in-guest make -j6 nativekernel KERNCONF=X86_64_GENERIC completed RC=0 with zero errors under -Werror (full log: findings/poc/_batch41/fix_build8.log). Behavior A/B intentionally skipped for this Info-tier item.