# DF-4970 VERDICT — xe pccard DINGO dead-code: CONFIRMED at source level, kernel path not instantiable on guest

## Bottom line
`xe_pccard_probe()` never sets `scp->dingo`. The loop at
`sys/dev/netif/xe/if_xe_pccard.c:311-323` iterates `i = 1, 2` and exits the
moment `i == XE_CARD_TYPE_FLAGS_DINGO` (`0x4`), so the `case
XE_CARD_TYPE_FLAGS_DINGO:` arm — the only writer of `scp->dingo` — is
unreachable. Every Dingo-era CEM56/REM56 combo card (table entries
`XE_PROD_MULTI_ID6`/`ID7` at `if_xe_pccard.c:119-122`, flags `MOHAWK|DINGO`)
is therefore mis-detected as a plain Mohawk.

## How it was proven
1. **Source trace (certain).** `i` takes values 1 (CE2), 2 (MOHAWK); the
   loop condition `i != 0x4` fails at 4, so 4 is never tested. No other code
   path in the tree writes `sc->dingo` (`grep dingo sys/dev/netif/xe/*`).
2. **Logic harness on the DragonFly guest** (`dingo_flags.c`, 3 runs):
   for all 10 card types the stock loop leaves `dingo = 0`; the two CEM56
   entries violate the invariant "table flags include DINGO ⇒ scp->dingo";
   the one-line `<=` variant restores it for exactly those two entries.
   Build/run logs: `build.log`, `run.log`, `run.2.log`, `run.3.log`.
3. **Fix compiles**: `fix.diff` applied to the guest's `/usr/src` copy builds
   `if_xe.ko` cleanly with `-Werror` (`fix_build.log`).

## Why not a kernel-path reproduction
The path requires a 16-bit PCMCIA bus with a Xircom CEM56/REM56 card
inserted. The audit guest (QEMU/KVM, X86_64_GENERIC) has no PCMCIA
controller device model (`env.txt`: no pccard module, no /dev/card*), so the
probe routine cannot be entered. Status is therefore **inconclusive**
(logic-proven, hardware-gated), consistent with the family precedent
(DF-4438/DF-4613).

## Impact ceiling (honest)
Functional, not memory-safety: with `dingo` unset,
- `xe_cemfix()` skips the Dingo DCOR0-4 configuration writes
  (`if_xe_pccard.c:201-208`) — 2ndF/modem interrupt routing and EEDIO setup
  never programmed for RealPort cards;
- `xe_activate()` never takes the Dingo aligned-ioport path
  (`if_xe.c:1915+`) and `xe_enable_intr`/`xe_disable_intr`/LED code apply
  the wrong "magic" modem bits (`if_xe.c:1170,1265,1282,1916`).
Result: CEM56/REM56 cards are brought up misconfigured/non-functional
(local device DoS for the inserting user; no kernel memory corruption).
Note: the Dingo branch of `xe_activate` contains a use-after-release read of
`port_res` (`if_xe.c`, `rman_get_start` after `bus_release_resource`) which
this bug currently keeps unreachable — fixing the flag loop without
checking that loop is *not* advised; both should be fixed together
(observed during this audit; filed as an observation, if_xe.c is pass-1
territory).

## Fix
`fix.diff`: change the loop bound to `i <= XE_CARD_TYPE_FLAGS_DINGO`.
Validated: harness fixed-loop output + `if_xe.ko` builds with `-Werror`.

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