• File: sys/dev/netif/pcn/if_pcn.c
• Lines: 798, 799, 746, 742, 745
• 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

pcn_rxeof copies the 16-bit cur_rx->pcn_rxlen field (range 0..65535) out of the NIC RX descriptor, subtracts ETHER_CRC_LEN (4), and assigns the result directly to m->m_len = m->m_pkthdr.len with no upper-bound check against the RX mbuf cluster size.

The cluster (allocated in pcn_newbuf via MGETHDR+MCLGET, then m_adj'd by ETHER_ALIGN=2) only backs MCLBYTES-2 = 2046 bytes from m_data.

A malicious or buggy PCIe device (or emulated PCnet; the driver itself notes VMware's PCnet emulation is broken at lines 432–437) that writes a descriptor with pcn_rxlen > 2050 and PCN_RXSTAT_ERR clear makes the network stack walk up to ~63533 bytes past the live cluster in ifp->if_input / ether_input / bpf_mtap / m_copydata: kernel heap information leak of stale slab contents and/or page-fault panic.

Also covers the pcn_rxlen < 4 underflow into negative m_len.

Direct sibling of DF-1410 (if_xe), DF-1478 (if_my), DF-1481 (if_vr), DF-1490 (if_tx), DF-1514 (if_ste), DF-1519 (if_lge), DF-1526 (if_sf), DF-1551 (if_sn).

Root cause

pcn_rxeof at sys/dev/netif/pcn/if_pcn.c:798-799:

m->m_len = m->m_pkthdr.len =
    cur_rx->pcn_rxlen - ETHER_CRC_LEN;

cur_rx->pcn_rxlen is declared u_int16_t in struct pcn_rx_desc (if_pcnreg.h:350).

The subtraction promotes to int giving range -4..65531. There is NO comparison of this value against MCLBYTES, against PCN_RXLEN (1536, the DMA buffer size programmed to the chip at pcn_newbuf:746), or against the usable cluster space.

Buffer geometry (pcn_newbuf lines 725–748):

• MGETHDR+MCLGET yields a cluster of exactly MCLBYTES=2048 bytes (sys/param.h:494-497, MCLSHIFT=11).
• Line 735/738 sets m_len=MCLBYTES.
• Line 742 m_adj(m_new, ETHER_ALIGN) advances m_data to ext_buf+2 and drops m_len to 2046.
• Line 745 c->pcn_rbaddr = vtophys(mtod(m_new, caddr_t)) DMA-targets ext_buf+2.
• So the chip writes into ext_buf[2..2+PCN_RXLEN-1] = ext_buf[2..1537]; the cluster ends at ext_buf[2047].

Legitimate hardware (buffer size PCN_RXLEN=1536) therefore reports pcn_rxlen<=1536, m_len<=1532, all within the cluster.

The driver relies entirely on the chip honoring the programmed buffer-size field; nothing in the driver enforces it.

A descriptor with pcn_rxlen=0xFFFF and pcn_rxstat with PCN_RXSTAT_ERR clear (e.g. only STP|ENP set, which is exactly what pcn_newbuf writes at line 748) is trusted unconditionally and yields m_len=65531 on a 2046-byte buffer.

The error-summary guard at line 779 (cur_rx->pcn_rxstat & PCN_RXSTAT_ERR) only filters packets the chip chose to flag; a descriptor written by a hostile/buggy device with ERR clear bypasses it.

There is no STP/ENP sanity check either (BUFF overflow would normally set ERR|BUFF, but again the driver does not enforce this for itself).

Threat

Attacker position: a malicious or compromised PCIe NIC function — VFIO/PCI passthrough of a crafted PCnet device into a DragonFlyBSD guest, a malicious Thunderbolt/USB-attached NIC, or buggy/emulated silicon (the driver's own comments at if_pcn.c:432-437 call out VMware's PCnet emulation as broken).

The attacker writes a DMA RX descriptor with pcn_rxlen>2050 and PCN_RXSTAT_ERR clear; pcn_rxeof reads that DMA memory at line 769 and trusts the length at line 798.

Under default driver config the chip is programmed to accept only <=1536-byte frames (PCN_RXLEN at pcn_newbuf:746), so a remote L2 attacker sending ordinary frames <=1518B cannot reach this path on correctly-functioning AMD Am79C97x silicon — hence Medium, not High.

Impact once triggered:

• kernel heap info-leak (up to ~63533 bytes, though practically bounded by the next unmapped page) via ether_input/BPF/raw-socket delivery, recovering stale packet contents or adjacent slab pointers;
• or kernel panic (Fatal trap 12: page fault while in kernel mode in bcopy/ether_input) when the OOB read crosses into an unmapped page.

Demonstrable locally without hardware via a kldload module that pokes a crafted descriptor and lets the next RINT interrupt run pcn_rxeof.

Exploit / PoC

Angle A (software proof; requires root to kldload but proves the unbounded-read defect with no special hardware, matching the verified sibling PoC strategy):

Build a kldload kernel module poc_pcnrx.c that

1. walks devclass pcn (devclass_find("pcn") + devclass_get_softc) to find each struct pcn_softc,
2. waits for IFF_UP and at least one packet to arrive so the ring is populated,
3. locates the current RX descriptor via sc->pcn_ldata->pcn_rx_list[sc->pcn_cdata.pcn_rx_prod],
4. atomically writes .pcn_rxlen = 0xFFFF, .pcn_rxstat = PCN_RXSTAT_STP|PCN_RXSTAT_ENP (no OWN, no ERR — see if_pcnreg.h:359-366),
5. lets the next RINT interrupt (or pcn_rxeof called manually via a poked CSR) run.

pcn_rxeof computes m_len=65531 on the 2048-byte cluster and calls ifp->if_input (line 802); bpf_mtap/ether_input/m_copydata traverse ~63533 bytes past ext_buf.

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

Success looks like Fatal trap 12: page fault while in kernel mode inside bcopy/ether_input, or — with slab grooming so the trailing bytes are mapped and a raw socket open on the interface — leaked kernel heap bytes observable in the received payload.

Angle B (no root; requires hostile PCIe): a QEMU/KVM guest with a passed-through or crafted Am79C972 function writes a DMA descriptor with the crafted pcn_rxlen/stat; the host running this driver hits the same path.

Recommended fix

Bound the NIC-reported length to the RX buffer size before using it as m_len. The check also closes the pcn_rxlen < ETHER_CRC_LEN underflow into negative m_len.

Apply at sys/dev/netif/pcn/if_pcn.c immediately before line 798:

--- a/sys/dev/netif/pcn/if_pcn.c
+++ b/sys/dev/netif/pcn/if_pcn.c
@@ -795,6 +795,20 @@ pcn_rxeof(struct pcn_softc *sc)

        PCN_INC(i, PCN_RX_LIST_CNT);

+       /*
+        * Validate the NIC-reported frame length against the RX
+        * buffer size.  The descriptor's buffer size was programmed
+        * to PCN_RXLEN (1536) in pcn_newbuf and the cluster backs
+        * only MCLBYTES - ETHER_ALIGN = 2046 bytes from m_data.
+        * A malicious or buggy PCIe device (or emulated PCnet)
+        * can otherwise report pcn_rxlen up to 65535, making the
+        * stack walk past the 2KB mbuf cluster.  Also rejects
+        * pcn_rxlen < ETHER_CRC_LEN which would underflow m_len.
+        */
+       if (cur_rx->pcn_rxlen < ETHER_HDR_LEN + ETHER_CRC_LEN ||
+           cur_rx->pcn_rxlen > MCLBYTES - ETHER_ALIGN + ETHER_CRC_LEN) {
+           IFNET_STAT_INC(ifp, ierrors, 1);
+           pcn_newbuf(sc, i, m);
+           continue;
+       }
+
        /* No errors; receive the packet. */
        IFNET_STAT_INC(ifp, ipackets, 1);
        m->m_len = m->m_pkthdr.len =

This matches the pattern applied across the sibling NIC drivers (DF-1410/1478/1481/1490/1514/1519/1526/1551).

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-1490 (twin, if_tx): 16-bit RX length OOB.
• DF-1514 (twin, if_ste): 13-bit RX length OOB.
• DF-1519 (twin, if_lge): 16-bit RX length OOB (jumbo).
• DF-1526 (twin, if_sf): RX length OOB + DMA overflow.
• DF-1551 (twin, if_sn): packet_length -= 6 underflow.
• DF-1452 (twin, if_ae): same RX-length OOB.
• DF-1131 (twin, bwn): same RX-length OOB.
• DF-1517 (twin, ath): wifi RX length OOB.