Summary

In amphy_status(), the branch handling DSCSR_10FDX (the "10Mbps full duplex" register bit, amphyreg.h:63) incorrectly OR's in IFM_HDX (half-duplex flag, 0x00200000) instead of IFM_FDX (full-duplex flag, 0x00100000). This reports the link as half-duplex when the PHY has negotiated 10Mbps full-duplex with a non-autonegotiating link partner, contradicting every other full-duplex branch in the same function.

Root cause

At amphy.c:263-271, when autoneg is enabled (BMCR_AUTOEN set) but the link partner lacks autonegotiation (ANER_LPAN clear, line 242), the driver reads MII_AMPHY_DSCSR (line 263) and selects media based on its speed/duplex bits. The branches are:

• DSCSR_100FDX → IFM_100_TX|IFM_FDX (amphy.c:264-265) CORRECT
• DSCSR_100HDX → IFM_100_TX (amphy.c:266-267) CORRECT (no FDX)
• DSCSR_10FDX → IFM_10_T|IFM_HDX (amphy.c:268-269) WRONG
• DSCSR_10HDX → IFM_10_T (amphy.c:270-271) CORRECT (no FDX)

The register defines at amphyreg.h:61-64 unambiguously label DSCSR_10FDX (0x2000) as "10Mbps full duplex". The parallel ANLPAR_10_FD autoneg branch at amphy.c:251-252 correctly uses IFM_10_T|IFM_FDX. This is a copy-paste error: IFM_FDX was mistyped as IFM_HDX. IFM_FDX (0x00100000) and IFM_HDX (0x00200000) are distinct, non-overlapping flags per if_media.h:303-304.

Threat model & preconditions

• Attacker position: remote — anyone who controls the link partner PHY.
• Privileges gained or impact: duplex-mismatch packet loss / availability degradation on the affected interface. No memory corruption or privilege escalation.
• Required config or capabilities: PHY is AMD AM79C873 / Davicom DM9101/DM9102/DM9601 (matched by amphys[] table, amphy.c:73-78).
• Reachability: (1) BMCR_AUTOEN set (autoneg enabled); (2) link partner is NOT autonegotiation-capable (ANER_LPAN clear); (3) PHY resolves to 10Mbps full-duplex (DSCSR_10FDX set). An attacker who controls the link partner PHY (e.g., a directly connected malicious device forcing 10baseT-FDX without autoneg) can drive the kernel's mii_media_active to report half-duplex. MAC drivers that read mii_media_active to program their duplex register will then configure the MAC for half-duplex while the actual link is full-duplex, producing a classic duplex-mismatch condition: massive collisions, late collisions, and severe packet loss.

Proof of concept

This is a functional/status-reporting defect, not a memory-corruption primitive; there is no exploit chain to escalate. To reproduce the misreport on a system with an AM79C873-class NIC:

1. Connect a link partner that forces 10baseT full-duplex WITHOUT advertising autonegotiation capability (e.g., a managed switch port set to speed 10 / duplex full / no negotiate, or a directly attached device forcing 10FDX).
2. On the DragonFlyBSD host: ifconfig <nic0> media autoselect && ifconfig <nic0> up
3. Observe: ifconfig <nic0> / ifmstatus reports media: Ethernet 10baseT/UTP half-duplex instead of full-duplex.
4. Run netperf / iperf to observe throughput collapse and collision counters climbing due to the duplex mismatch.

Impact

Functional misreport causing packet loss / availability degradation. No kernel panic, no code execution.

Recommended fix

Change IFM_HDX to IFM_FDX on line 269. Unified diff:

--- a/sys/dev/netif/mii_layer/amphy.c
+++ b/sys/dev/netif/mii_layer/amphy.c
@@ -265,7 +265,7 @@
        else if (par & DSCSR_100HDX)
            mii->mii_media_active |= IFM_100_TX;
        else if (par & DSCSR_10FDX)
-           mii->mii_media_active |= IFM_10_T|IFM_HDX;
+           mii->mii_media_active |= IFM_10_T|IFM_FDX;
        else if (par & DSCSR_10HDX)
            mii->mii_media_active |= IFM_10_T;
    } else {

References

• sys/dev/netif/mii_layer/amphyreg.h:63 — DSCSR_10FDX = 0x2000 ("10Mbps full duplex").
• sys/dev/netif/mii_layer/amphy.c:251-252 — parallel autoneg branch that correctly uses IFM_FDX.
• sys/net/if_media.h:303-304 — distinct, non-overlapping IFM_FDX / IFM_HDX flag values.

Timeline

• 2026-07-25 Discovered during automated audit.
• 2026-07-25 Reported to DragonFlyBSD security contact.