# DF-3333 — VERDICT

**Finding:** escalation of the DF-0359 ring-state corruption into an
out-of-bounds slot access and OOB *write* in `netmap_transmit()`.

## Reproduced? YES — in a real kernel, with the verbatim functions.

Constraint (same as DF-3332): the netmap subsystem does not compile on this
DragonFly tree (`netmap_kern.h:747` / `ifnet.if_unused7` removed; no
sys/conf/files entry; no netmap.ko).  The two vulnerable functions —
`netmap_rxsync_from_host()` (netmap.c:884-929) and the `netmap_transmit()`
insert block (netmap.c:2011-2044) — plus `nm_kr_rxpos()`
(netmap_kern.h:540-556) depend on none of the rotted machinery, so they run
**verbatim** in a KLD (`df3333_kmod.c`, stubs documented in-file; the only
additions are marked INSTRUMENTATION) against a fake pool of
`[ ring | 1024 real slots | 1024 marker slots ]`.

### Run 1 — vulnerable variant (dmesg.txt / run.log)

The choreography replays, ~4.19M times, exactly what an mmap()ed userspace
thread can write before each `NIOCRXSYNC` on the host ring:

    ring->reserved = 0xffffffff;  ring->avail = 1;   /* resvd+avail wraps to 0,
                                                        passes the >= lim+1 guard
                                                        (netmap.c:910) */
    ring->cur = 1023 (then 0 alternating);

Result (dmesg):

    df3333: choreography start (target hwcur>lim with hwavail<lim)
    df3333: after 4194302 pairs: hwcur=2048 hwavail=0 (0x0)  <-- hwcur OUT OF RANGE
    df3333: transmit used slot index 1024 (lim = 1023)  <-- OUT OF BOUNDS
    df3333: RESULT OOB WRITE CONFIRMED at slot[1024] (1 slots past end of ring)  [VULNERABLE]

The `slot->len = 60; slot->flags = 1` writes of netmap.c:2037-2038 landed in
the marker region — **past the end of the slot array** — proving the OOB
write, exactly at the index derived in the analysis (the reachable sum
`hwcur+hwavail` is ≡ 0 mod num_slots, so the first OOB index is 1024).

### Run 2 — FIXED variant (`-DDD3333_FIXED`: second `pos %= num_slots` in
nm_kr_rxpos — the netmap_kern.h part of fix.diff) (run.fixed.log)

    df3333: transmit used slot index 0 (lim = 1023)
    df3333: RESULT no write past ring end (pos=0)  [FIXED]

(The ring corruption itself — hwcur=2048 — remains; that is DF-0359's bug,
addressed by the netmap.c part of fix.diff, the overflow-proof resvd guard.)

## Impact assessment (why Low)

* The OOB write lands **inside the shared netmap memory pool** (the ring
  object is followed by other pool objects/slack; netmap_mem2.c packs rings
  into clusters).  The whole pool is RW-mapped to the netmap clients, so on
  its own this write crosses no privilege boundary — the attacking user
  could write the same bytes directly through their own mapping.
* The security meaning is **cross-client corruption**: the pool is the
  *global* allocator shared by all netmap fds system-wide
  (netmap_get_memory_locked → &nm_mem), so client A (wheel) can corrupt
  client B's ring header/slot/buffer state — including buffer indices
  (`buf_idx` values copied by netmap_sw_to_nic / read by other clients'
  syncs), which chains into DF-0547's cross-adapter double-free/aliasing.
* Practically gated by /dev/netmap permissions (0660 root:wheel on this
  vintage) and — on this tree — by the subsystem not compiling at all.

## Exploit chain (steps, not carried to uid0)

1. NIOCREGIF host ring + mmap (wheel group);
2. NIOCRXSYNC×~8.4M with reserved=0xffffffff/avail=1 lie → hwcur=2048,
   hwavail=0 (underflowed from DF-0359's arithmetic);
3. host stack sends any packet via the interface → netmap_transmit writes
   len/flags at slot[1024] — one slot past the victim ring.

## Kernel references

* sys/net/netmap/netmap.c:909-914 — overflowable resvd+avail guard
* sys/net/netmap/netmap.c:916-921 — hwcur stored out of range, hwavail underflow
* sys/net/netmap/netmap_kern.h:541-545 — nm_kr_rxpos single subtract
* sys/net/netmap/netmap.c:2034-2038 — OOB slot index → OOB len/flags write

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