# DF-3332 — VERDICT

**Finding:** `netmap_grab_packets()` (sys/net/netmap/netmap.c:723-760) computes
its loop terminator `k` from the user-writable shared-memory field
`ring->reserved` with a sign error (`k += n` at netmap.c:740 instead of
`k -= n`). `netmap_txsync_to_host()` validates `ring->cur` (netmap.c:851-857)
but nothing validates `reserved`; with `cur < reserved` the computed `k`
(= cur + num_slots + reserved ≥ num_slots) lies outside the range the loop
variable can ever reach (`nm_next()` wraps within [0, num_slots-1]), so
`for (n = kring->nr_hwcur; n != k;)` never terminates.

## Was it reproduced? YES — in a real kernel, with the verbatim function.

Constraint: the netmap subsystem of this DragonFly tree **does not compile**
(netmap_kern.h:747 dereferences `ifnet.if_unused7`, which no longer exists in
sys/net/if_var.h; `sys/conf/files` contains no netmap entries; no kernel
config registers it; no netmap.ko exists in /boot/kernel — `kldload netmap`
fails and `cd /usr/src/sys/net/netmap && make` dies with 15 hard errors,
all `if_unused7`).  This was already established by the earlier evidence
packs of DF-0401/DF-0546/DF-0547/DF-0616 and re-confirmed this run
(env.txt).

The vulnerable loop itself depends only on `ring->cur`, `ring->reserved`,
`nkr_num_slots`, `nr_hwcur`, and `slot[].len/flags` — none of the rotted
machinery.  `df3332_kmod.c` therefore carries the function **verbatim**
(only additions: iteration counter + bail-out for diagnostic mode, both
marked `INSTRUMENTATION`; `m_devget`/`BDG_NMB`/`NETMAP_BDG_BUF_SIZE`/`D`
stubbed — values irrelevant to loop control, the real macros are
bounded/clamped per netmap_kern.h:838-857) and runs it inside a stock
DragonFly 6.5-DEVELOPMENT kernel as a KLD, driven by exactly the ring state
an mmap()ed unprivileged (wheel-group) thread can write:

### Run 1 — diagnostic (mode 0), vulnerable variant (dmesg.txt, run.log)

    df3332: k=1025 lim=1023 nr_hwcur=0 num_slots=1024
    df3332: RESULT iterations=10241 bailed=1 mbufs=0
            (loop WOULD NOT TERMINATE (bailed out))

k=1025 is unreachable by the loop variable (0..1023) — without the
instrumentation bail-out the loop provably never exits.  Each iteration also
executes the unconditional `D()` kprintf of netmap.c:749.

### Run 2 — diagnostic, FIXED variant (`k -= n`) (run.fixed.log)

    df3332: k=1023 lim=1023 nr_hwcur=0 num_slots=1024 [FIXED]
    df3332: RESULT iterations=1023 bailed=0 mbufs=0 (loop terminated)

Exactly the expected 1023 iterations (hwcur 0 → k 1023).  The one-line fix
eliminates the non-termination.

### Run 3 — pure mode (mode 1), vulnerable variant (run.kernelflood.full.log)

`sysctl -n debug.df3332.trigger=1` executed from ssh **never returned**
("NEVER_PRINTS" marker absent after the call; ssh client killed at 25 s).
Observed afterwards:

* load average 0.00 → 0.63+ and climbing (1 of 6 CPUs pegged);
* serial console flooding at ~100 lines/s with
  `grab_packets [153] bad pkt at N len 0` — 40,088 flood lines captured
  (run.kernelflood.full.log; excerpt in panic.txt);
* new ssh logins intermittently stall during banner exchange (three sessions
  timed out, one succeeded) — system-wide degradation;
* `kill -9` cannot be delivered: the thread never returns to user mode, so
  no signal can take effect (definitional for a kernel-mode non-yielding
  loop; the process is still present and spinning — ps attempts themselves
  stalled behind console contention);
* **`shutdown -p now` never completed** — `vm.sh reset` had to force-kill
  QEMU (the spinning thread blocks system shutdown: further proof of the
  DoS severity).

## Exploit chain / impact

Local denial of service by any principal that can open /dev/netmap
(mode 0660 root:wheel per netmap.c:2237 on this vintage; the code lineage is
FreeBSD's netmap.c r257176 where the same loop shipped): one NIOCREGIF
(NETMAP_SW_RING) + mmap + one NIOCTXSYNC → unkillable kernel thread, console
flood, unbounded mbuf allocation variant (lens ≥ 14) exhausts mbufs.
Not a memory-corruption primitive: all slot accesses stay in-bounds
(`n` cycles 0..lim; `slot->len` checked against 14..NETMAP_BDG_BUF_SIZE at
netmap.c:748; `BDG_NMB` clamps buf_idx) — impact is purely availability.
The write variant can also corrupt ring accounting (avail/hwcur reset at
netmap.c:865-866 after break), but no privilege boundary is crossed.

## Fix validation

`fix.diff` (one line: `k += n;` → `k -= n;` at netmap.c:740, which also
fixes DF-0358's wrong-slot delivery).  A full fixed *netmap* kernel build is
impossible on this tree (subsystem bit-rot), so validation was done with the
**-DDD3332_FIXED variant of the same verbatim function inside the same real
kernel**: non-termination eliminated (Run 2).  fix_status="fixed" with that
caveat.

## Kernel references

* sys/net/netmap/netmap.c:731-741 — the arithmetic (sign error)
* sys/net/netmap/netmap.c:742-759 — the non-terminating loop
* sys/net/netmap/netmap.c:851-857 — only `cur` is validated, `reserved` never
* sys/net/netmap/netmap.c:1443-1445 — NIOCTXSYNC host-ring dispatch
* sys/net/netmap/netmap_kern.h:196-201 — nm_next() wrap range

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