• File: sys/dev/netif/tx/if_tx.c
• Lines: 557, 582, 583, 600, 603, 1429
• Severity: Medium
• CVSS: CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:H
• CWE: CWE-125 Out-of-bounds Read
• Confidence: certain

Summary

epic_rx_done() reads the NIC DMA descriptor's 16-bit rxlength field, subtracts ETHER_CRC_LEN, and assigns the result directly to m->m_pkthdr.len = m->m_len with no upper-bound check against the RX buffer size (MCLBYTES=2048, programmed at line 1429).

For a malicious/buggy PCIe NIC reporting rxlength > 2048 (up to 65535), the mbuf is handed to ifp->if_input (ether_input/BPF/m_copydata) with m_len up to 65531, walking up to ~63483 bytes past the 2KB cluster into kernel heap: info leak of stale heap contents and/or panic on an unmapped page.

The 16-bit field makes this a far larger OOB reach than the 12-bit (if_xe/ if_my) and 11-bit (if_vr) siblings. A separate underflow exists: rxlength < 4 makes len (declared u_int16_t at line 557) wrap to 65532..65534, catastrophic.

Root cause

epic_rx_done() at sys/dev/netif/tx/if_tx.c:554-610.

Line 557: u_int16_t len; — len is 16-bit unsigned.

Line 582: len = desc->rxlength - ETHER_CRC_LEN; — desc->rxlength is volatile u_int16_t (sys/dev/netif/tx/if_txreg.h:202), a 16-bit NIC-DMA field ranging 0..65535. ETHER_CRC_LEN=4 (sys/net/ethernet.h:33).

The subtraction promotes to int, then truncates back to u_int16_t on assignment, so rxlength<4 wraps len to 0xFFFE..0xFFFC.

Line 583: m = buf->mbuf; — the live RX mbuf whose cluster was allocated at epic_init_rings:1422 via m_getcl(M_NOWAIT, MT_DATA, M_PKTHDR), giving exactly MCLBYTES=2048 bytes of backing (MCLSHIFT=11, sys/sys/param.h:494-497). m_getcl does NOT zero the cluster (sys/kern/uipc_mbuf.c:1175), so trailing bytes are stale heap.

Line 600: m->m_pkthdr.len = m->m_len = len; — no comparison of len against MCLBYTES (2048) or against desc->buflength (set to MCLBYTES at line 1429: desc->buflength = MCLBYTES;).

Line 603: ifp->if_input(ifp, m, NULL, -1); — hands the over-length mbuf to ether_input, which traverses m_len bytes (BPF tap, header parse, m_copydata on forward).

The only status guard is line 575 if ((desc->status & 1) == 0) (NIC 'OK' bit clear ⇒ error). There is NO length validation anywhere between the DMA descriptor read (line 565) and the m_len assignment (line 600).

The descriptor's buflength (2048) tells the NIC the max DMA it may write, but rxlength is reported independently; a device that reports rxlength > buflength while keeping bit 0 set is never caught by the driver.

For rxlength in [2053, 65535]: len in [2049, 65531], m_len exceeds the 2048 cluster by 1..63483 bytes.

For rxlength in [0, 3]: len wraps to [65532, 65534].

Threat

Attacker position: a malicious or compromised PCIe NIC function (VFIO/PCI passthrough to a QEMU/KVM guest, a hostile Thunderbolt/ExpressCard NIC, or SMC83C170 silicon errata) that writes a DMA descriptor with rxlength > 2048 (or rxlength < 4) and status bit 0 set. The driver reads desc->rxlength and desc->status directly from DMA memory (line 565, via sc->rx_desc which is the DMA-coherent ring at vtophys(sc->rx_desc) programmed at line 1083) and trusts them unconditionally.

Under default driver config the SMC83C170 is a 10/100 controller with no jumbo support and RXCON_DEFAULT (if_txreg.h:166) does not set RXCON_SAVE_ERRORED_PACKETS, so a remote L2 attacker sending ordinary frames <=1518B cannot reach this path on correctly-functioning silicon — hence Medium (adjacent-vector), not High. This matches the threat model and severity of the sibling findings DF-1410 (if_xe), DF-1478 (if_my), DF-1481 (if_vr), DF-1452 (if_ae), DF-1131 (bwn).

Impact once triggered:

• (a) kernel heap info-leak of up to ~63483 bytes of uninitialized/stale heap (prior packet contents, adjacent slab metadata) delivered up the network stack to a socket an attacker reads — substantially larger than the ~2043-byte leak of the 12-bit siblings due to the 16-bit field;
• (b) kernel panic (A:H availability) when the OOB read crosses an unmapped page boundary, which the large reach makes far more likely than in the siblings.

Exploit / PoC

PoC angle A (software proof, proves the unbounded-read defect with no special hardware): a kldload kernel module that

1. walks devclass tx device_list to find each epic_softc_t,
2. waits for the interface to be IFF_UP (so epic_init_rings has populated sc->rx_desc[i].bufaddr with live clusters),
3. locates the descriptor at sc->cur_rx via sc->rx_desc + sc->cur_rx,
4. atomically writes sc->rx_desc[cur_rx].rxlength = 65535 and sc->rx_desc[cur_rx].status = 0x8001 (clear the 'owned by NIC' bit 0x8000 to mark driver-owned, set bit 0 'OK'),
5. triggers epic_rx_done on the next interrupt or by directly invoking it.

epic_rx_done computes len = 65535-4 = 65531, assigns m_len=65531 to a 2048-byte cluster, calls ifp->if_input.

Success: Fatal trap 12: page fault while in kernel mode inside ether_input/bcopy (typical when the read crosses a page boundary), or — with slab grooming so trailing 63483 bytes stay mapped — leaked kernel heap observable via an AF_RAW socket reading the oversized frame.

Build: cc -c -DKLDLOAD -I/sys poc_txrx.c; ld -d -r poc_txrx.o; kldload ./poc_txrx.ko.

PoC angle B (no root, requires hostile PCIe): a QEMU/KVM guest with a passed-through or emulated SMC83C170 function writes the crafted rxlength/status via DMA; the host running this driver hits the same path.

Recommended fix

Bound the NIC-reported length to the RX buffer geometry (MCLBYTES) before using it as m_len, and reject the unsigned-underflow case (rxlength < ETHER_CRC_LEN). This matches the fix applied in every sibling DFly NIC driver.

--- a/sys/dev/netif/tx/if_tx.c
+++ b/sys/dev/netif/tx/if_tx.c
@@ -579,6 +579,22 @@ epic_rx_done(epic_softc_t *sc)
            continue;
        }

-       /* Save packet length and mbuf contained packet */
-       len = desc->rxlength - ETHER_CRC_LEN;
-       m = buf->mbuf;
+       /* Save packet length and mbuf contained packet.
+        *
+        * Validate the NIC-reported frame length against the RX
+        * buffer size.  The descriptor buflength was programmed to
+        * MCLBYTES in epic_init_rings; a malicious/buggy PCIe
+        * device can otherwise report rxlength up to 65535 (16-bit
+        * field) while clearing the error bit, making the stack
+        * walk far past the 2KB mbuf cluster.  Also reject the
+        * underflow case rxlength < ETHER_CRC_LEN.
+        */
+       if (desc->rxlength < ETHER_HDR_LEN + ETHER_CRC_LEN ||
+           desc->rxlength > MCLBYTES) {
+           IFNET_STAT_INC(&sc->sc_if, ierrors, 1);
+           desc->status = 0x8000;
+           continue;
+       }
+
+       len = desc->rxlength - ETHER_CRC_LEN;
+       m = buf->mbuf;

        /* Try to get mbuf cluster */

The check runs after the error-bit guard (line 575) and before the m_getcl replacement (line 586), so on rejection the existing cluster is retained (buf->mbuf untouched) and the descriptor is simply re-armed for the NIC without losing the buffer. The lower bound ETHER_HDR_LEN + ETHER_CRC_LEN (18+4=22) rejects runts/underflow; the upper bound MCLBYTES caps the OOB.

Related findings

• DF-1410 (twin, if_xe): 12-bit RX length OOB.
• DF-1478 (twin, if_my): 12-bit RX length OOB.
• DF-1481 (twin, if_vr): 11-bit RX length OOB.
• DF-1452 (twin, if_ae): same RX-length OOB.
• DF-1131 (twin, bwn): same RX-length OOB.