# DF-3721 — mxge_dma_test divides by a firmware-returned counter with no zero check: kernel #DE panic at attach / watchdog recovery

## Vulnerability

`sys/dev/netif/mxge/if_mxge.c` `mxge_dma_test()` (:430-488) computes DMA
benchmark numbers from the firmware command response:

```c
sc->read_dma      = ((cmd.data0>>16) * len * 2) / (cmd.data0 & 0xffff);  /* :459  */
sc->write_dma     = ((cmd.data0>>16) * len * 2) / (cmd.data0 & 0xffff);  /* :469  */
sc->read_write_dma= ((cmd.data0>>16) * len * 2 * 2) / (cmd.data0 & 0xffff); /* :479 */
```

`cmd.data0` is the **device-written** result register
(`MXGEFW_DMA_TEST`/`UNALIGNED_TEST`: upper 16 bits repetitions, lower 16
bits 0.5 µs ticks — mxge_mcp.h).  The lower half is the **divisor** and is
never checked: a device that returns `repetitions<<16 | 0` (glitched SRAM,
hung DMA engine, hostile firmware) makes the kernel execute an integer
division by zero → `#DE` → **panic**.

Reachability: `mxge_dma_test` runs from `mxge_reset` (:1225, i.e. every
attach :4363 and every `mxge_open` after reset :3341) and from
`mxge_firmware_probe` (:551).  A device that passed the preceding
`MXGEFW_CMD_RESET` handshake but returns a zero tick count panics the host
during boot-time probe or during the watchdog-recovery path
(`mxge_watchdog_reset` :3658-3664) — turning a flaky NIC into a panicking
NIC precisely when the system is trying to recover it.

## Threat model

Device-fault / hostile-device (same premise as DF-3716/3718/3720); the
divisor is never host-derived.

## Verification

Hardware-gated (no Myricom NIC on the guest); source-certain; the
division-by-zero fault behavior itself is architectural (x86 #DE in kernel
context = fatal trap).  `inconclusive` per family convention.

## Fix

`fix.diff`: check `(cmd.data0 & 0xffff) == 0` after each successful test
command and bail out with `EIO` through the existing `abort` path
(git-apply clean).