DF-5077 — acphy_attach 'no media present' branch → hub panic("ifmedia_set") at attach

File: sys/dev/netif/mii_layer/acphy.c:169-172 (6th leaf of the DF-4930 / DF-4957 / DF-4981 / DF-5003 / DF-5053 empty-media family; hub = DF-5001)

Build (on the guest)

mkdir -p /root/df5077 && cp miihub.c Makefile build.sh run.sh /root/df5077/
sh /root/df5077/build.sh        # make -m /usr/share/mk -> miihub.ko (rc=0)

Run (on the guest)

sh /root/df5077/run.sh

1. hw.miihub_fixcheck=1 — the FIXED hub walk (empty list → add IFM_ETHER|IFM_AUTO → ifmedia_set) must survive with ifm_cur != NULL.
2. hw.miihub_fire=1 — the VERBATIM miibus_mediainit walk (mii.c:238-244) on the EMPTY media list — exactly the state produced when acphy_attach takes its 'no media present' branch.

Expected

• fixcheck: survives, prints ifm_cur=0xfffff8... (non-NULL), rc=0.
• fire: ifmedia_set: no match for 0x0/0xfffffff then panic: ifmedia_set — trace ifmedia_set <- miihub_fire <- sysctl; guest goes down into DDB (panic.txt).

Trigger precondition (why end-to-end is not_reproduced)

Firing the leaf itself requires an Altima AC101/AC101L-family PHY whose ID registers match acphys[] (acphy.c:107-113) while its BMSR reports ZERO media capability at attach time (faulty PHY, or mii_capmask masking the media bits). PHY register behavior is not emulatable in the QEMU guest — same class as the family leaves (DF-4930 verdict). The kernel-side sink of the chain is nonetheless proven fresh on this guest (panic.txt), and the family-wide fix (DF-5001 hub guard) is build-validated (fix_build.log, miibus.ko rc=0, 0 errors/0 warnings) and behavior-validated (fixcheck).

DF-5077 VERDICT — acphy empty-media leaf (DF-4930 family), sink proven, leaf trigger hardware-gated

Status: not_reproduced (end-to-end), impact none, confidence likely — the exact family treatment of DF-4930 (atphy), applied to the 6th leaf.

Root cause (code-certain)

acphy_attach():

• acphy.c:167 sc->mii_capabilities = PHY_READ(sc, MII_BMSR) & ma->mii_capmask;
• acphy.c:169 if (sc->mii_capabilities & BMSR_MEDIAMASK)
• acphy.c:170 mii_phy_add_media(sc);
• acphy.c:171 else
• acphy.c:172 kprintf("no media present"); ← zero media → nothing added
• acphy.c:175 MIIBUS_MEDIAINIT(sc->mii_dev); → miibus_mediainit

aggravated by acphy.c:161 sc->mii_flags |= MIIF_NOISOLATE; — the IFM_NONE fallback inside mii_phy_add_media is gated off for MIIF_NOISOLATE drivers (mii_physubr.c:229-232), so even a partial pass adds nothing without real BMSR media bits.

miibus_mediainit (mii.c:228-245) then walks the (empty) ifm_list, media stays 0, and the terminal ifmedia_set(&mii->mii_media, 0) (mii.c:244) hits DragonFly's ifmedia_match()==NULL → panic("ifmedia_set") (sys/net/if_media.c:174) at NIC attach — boot/attach-time DoS. Sibling leaves: atphy DF-4930, ciphy DF-4957, jmphy DF-4981, truephy DF-5003, qsphy DF-5053; the hub and the family-wide fix belong to DF-5001 (mii.c empty-list guard).

What was reproduced on the guest (fresh, this run)

• Sink panic: KLD replaying the verbatim hub walk against an EMPTY media list — the exact state acphy's no-media branch leaves — panicked the running stock kernel: ifmedia_set: no match for 0x0/0xfffffff → panic: ifmedia_set, trace ifmedia_set <- miihub_fire <- sysctl (panic.txt, guest down in DDB; console session hung mid-sysctl).
• Fix behavior: hw.miihub_fixcheck=1 (fixed walk: empty → add IFM_ETHER|IFM_AUTO → ifmedia_set) survived with ifm_cur=0xfffff8008d5a10c0 non-NULL — the downstream ife->ifm_media deref every mii *_service() performs is then safe (run.log).
• Fix build: DF-5001's hub-guard diff (this pack's fix.diff) applied to guest /usr/src, make -j4 in sys/dev/netif/mii_layer → miibus.ko rc=0, 0 error:/0 warning: (fix_build.log, 209 lines); sources reverted md5-verified pristine (2f16a4a6...), make clean.

Why the leaf itself cannot fire on this guest

acphys[] matches on PHY ID registers (acphy.c:107-113); the no-media branch additionally needs BMSR media bits == 0 (or fully masked) at attach. QEMU's NIC models do not emulate MII PHY register files. Same verdict class as DF-4930 ("no such PHY exists on the QEMU guest"). A hardware-fault / malicious-PHY precondition is required in the field — severity Low, no unprivileged trigger, no memory unsafety.

Negative results (pass-2 depth on this file)

• No service-entry KASSERT (DF-1973/DF-5009 family does NOT apply): acphy_service (acphy.c:189-196) uses the standard foreign-instance guard (ISO|PDOWN on MEDIACHG only); the miibus dispatch (mii.c:301-360) passes the shared ifm_cur to every child — verified harmless for acphy.
• Vendor register indexes all within the 5-bit MII space (acphyreg.h:37-76: 0x10..0x18 < 0x20) — no OOB register index; the LED config (MII_ACPHY_MCTL AC_MCTL_LED_SEL) is never programmed by this driver at all.
• Status decode (acphy.c:273-283): DIAG speed/duplex bits → IFM constants match acphyreg.h:53-54 — no amphy-DF-2101-style transcription error; the forced-media else copying ife->ifm_media wholesale is the upstream shape shared across the family (cosmetic at most).
• Probe table sentinel MII_PHYDESC_NULL present (acphy.c:112).
• Reset waits: mii_phy_reset (mii_physubr.c:183-213) has the 500us + 100x1ms settle loop; the added PHY_WRITE(MII_ACPHY_INT, 0) (acphy.c:290) needs no wait; MIIF_NOISOLATE correctly suppresses the post-reset ISO write.
• No copyin/copyout, no privilege surface, no locks/refcounts to race.

Artifacts

miihub.c (DF-5001's KLD, verbatim — it models exactly this leaf's state), panic.txt (fresh sink panic + fixcheck transcript), run.log, fix_build.log (miibus.ko with hub fix), fix.diff (DF-5001 hub guard — the family-wide fix covering this leaf), env.txt.

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.