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