DF-5090 — ruephy(4) is dead code: unreachable latent leaf of the mii attach-panic family

File audited: sys/dev/netif/mii_layer/ruephy.c (284 LOC, pass 2)

What this pack proves (statically — no guest applicable)

ruephy_probe() (ruephy.c:96) only accepts a miibus child whose grandparent device name is exactly "rue" — the Realtek RTL8150 USB NIC driver. No driver, devclass, kernel config entry, or module named rue exists anywhere in this tree. Therefore ruephy_attach/_service/_status/_reset are unreachable on every kernel buildable from this source, and the three latent family defects below can never fire today:

1. Empty-media attach panic (ruephy.c:141-145) — DF-4930/DF-4957/DF-4981/ DF-5003/DF-5053 leaf family, hub DF-5001: no media present branch skips mii_phy_add_media(), so miibus_mediainit (mii.c:228-245) calls ifmedia_set() on an empty list → panic("ifmedia_set").
2. Service-entry KASSERT (ruephy.c:161) — DF-1973/DF-5009 family; note DragonFly stock X86_64_GENERIC enables INVARIANTS (config line 56), so this assert is live on stock kernels — held in check only by the probe gate and by the non-zero-instance refusal at ruephy.c:121-124.
3. Unguarded ifm_cur deref (ruephy.c:282) in the forced-media branch of ruephy_status() — shared upstream pattern; NULL only via path (1).

Reproduce

cd /home/maxx/dfbsd/dfbsd
sh findings/poc/DF-5090/proof.sh        # exit 0 + "PROOF OK"

Expected: all seven invariants hold (proof.log); decisive output is section A — the only "rue" string literals in the entire tree are ruephy.c's own probe gates.

Why no QEMU run

Phase V is exempt for Info hardening findings. Beyond the exemption, a runtime PoC is unconstructible: triggering attach requires a rue NIC driver, which does not exist; manufacturing a fake one on the guest would demonstrate the already-replay-proven DF-4930 family mechanism (see the truephy/qsphy packs), not anything new about this file. The exhaustive tree/build-system proof here is strictly stronger than any single-guest observation.

Fix

Retire the driver (and its ruephyreg.h, plus the never-compiled u4b orphans sys/bus/u4b/net/ruephy.c + ruephyreg.h). If rue(4) is ever ported, the DF-5001 hub guard must land with it.

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