# VERDICT — DF-5090 (ruephy.c dead code / unreachable family leaf)

**Status: untested (static verification, Phase V exempt — Info finding, no runtime trigger constructible).**
**Impact: none (today). Confidence: certain. Attempts: 0 (no guest run).**

## What was audited

Full pass-2 audit of `sys/dev/netif/mii_layer/ruephy.c` (284 LOC) against the
mii family checklist (empty-media branch, service KASSERT, status decode,
reset, probe sentinel, reachability), plus full pass-2 audit of the consumer
chain: probe/attach/service/status call paths, `mii.c` (miibus_mediainit,
mii_softc_init, mii_phy_add_media), `mii_physubr.c` (mii_phy_reset,
mii_phy_update), `ukphy.c` (ukphy_detach), newbus attach/detach semantics
(`sys/kern/subr_bus.c:2100-2137`), KASSERT gating (`sys/sys/systm.h:94-122`),
and kernel configs (`sys/config/X86_64_GENERIC`).

## The decisive chain of evidence

1. `ruephy_probe()` at ruephy.c:96 gates attach on
   `strcmp(device_get_name(parent), "rue") == 0`, where parent is the
   grandparent of the miibus child (i.e. the USB NIC device).
2. Exhaustive tree search (proof.sh section A-D) proves no driver named
   `rue` exists in this source tree:
   - no `DRIVER_MODULE(rue, ...)`, no `driver_t` registering the name
     `"rue"` (the only two `"rue"` literals in sys/ are the probe gates
     themselves: `sys/dev/netif/mii_layer/ruephy.c:96` and the orphaned
     `sys/bus/u4b/net/ruephy.c:101`);
   - no `device rue` in any kernel config or platform;
   - no `if_rue*`/`rue.c` source anywhere;
   - `sys/bus/u4b/net/` — the USB NIC driver directory — contains
     `ruephy.c`/`ruephyreg.h` imported from FreeBSD but referenced by no
     build file (`sys/conf/files`, no u4b Makefile): never compiled.
     The RTL8150 NIC driver was simply never ported to DragonFly.
3. The audited copy IS compiled (`sys/conf/files:1094`,
   `dev/netif/mii_layer/ruephy.c optional miibus`) and registers a driver on
   the miibus devclass — it probes every MII child and always returns ENXIO.
   Pure dead weight; zero attack surface.

Therefore the three latent patterns are unreachable:
- empty-media branch ruephy.c:141-145 (DF-4930/DF-5001 family — panic via
  mii.c:228-245 `ifmedia_set` on empty list);
- service-entry KASSERT ruephy.c:161 (DF-1973/DF-5009 family) — live on stock
  kernels because `X86_64_GENERIC:56` enables INVARIANTS, but additionally
  defused by the instance!=0 refusal at ruephy.c:121-124 (a second ruephy can
  never attach to create the multi-PHY mismatch), and unreachable regardless;
- unguarded `mii->mii_media.ifm_cur->ifm_media` deref ruephy.c:282 (NULL only
  via the empty-media path, which panics earlier at mediainit).

## Other candidates considered and killed (negative result)

- `device_get_parent(device_get_parent(dev))` NULL deref in probe: miibus
  children are only created by an attached miibus whose own parent (the NIC)
  exists; not attacker-reachable.
- ENXIO-at-ruephy.c:121-124 path after `mii_softc_init` leaving an unlinked,
  zeroed softc: newbus does NOT call device_detach after a failed attach
  (subr_bus.c:2115-2123 resets driver/state to DS_NOTPRESENT), so
  `ukphy_detach`'s `LIST_REMOVE` (ukphy.c:178-186) cannot run on it.
- `ruephy_reset`: `mii_phy_reset` (mii_physubr.c:183) is a bounded 100×10ms
  poll; MIIF_NOISOLATE is honored (no BMCR_ISO write); the follow-up
  `PHY_WRITE(BMCR_AUTOEN)` is a 16-bit chip register write via the miibus
  method — chip-side only, no kernel memory involvement.
- Status decode: double-read latch idiom on MSR is correct; ISO branch clears
  status; 10/100-only decode matches RTL8150 (no gigabit bits exist to miss).

## Bottom line

The file is a provably-unreachable carrier of three already-filed family
defects. The security-relevant finding is the *unreachability* itself: today's
impact is none; the exposure is that any future port of rue(4) (FreeBSD
if_rue.c) instantly activates (1) an INVARIANTS-live KASSERT and (2) the
DF-4930 attach-panic leaf on stock kernels unless the DF-5001 hub guard lands
with it. Recommended action: retire the file and the u4b orphans.

No guest was booted; nothing to reset. Fix validation not applicable
(dead code; the "fix" is deletion, not a behavioral patch).

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

(No fix.diff for this item: documented recommendation only - see Fix above.)