• File: sys/dev/netif/my/if_my.c
• Lines: 1105, 1106, 1108, 1131, 1076
• 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

my_rxeof extracts the 12-bit FLNG field (range 0..4095) from the NIC descriptor status word, subtracts ETHER_CRC_LEN, and assigns the result directly to m->m_pkthdr.len = m->m_len with no upper-bound check against MCLBYTES (2048) — the actual size of the RX mbuf cluster programmed into the descriptor RBS field at my_newbuf line 1076 ((MCLBYTES-1)<<MY_RBSShift).

For FLNG in [2053, 4095] (total_len 2049..4091), m_len exceeds the 2KB cluster and the subsequent ether_input / ifp->if_input call (line 1134) walks up to ~2043 bytes past the cluster into kernel heap: information leak of stale heap contents and/or panic on unmapped page.

Direct sibling of DF-1410 (if_xe), DF-1452 (if_ae), DF-1131 (bwn).

Root cause

Line 1105: total_len = (rxstat & MY_FLNGMASK) >> MY_FLNGShift. MY_FLNGMASK=0x0fff0000 (if_myreg.h:229) is a 12-bit field, so FLNG ranges 0..4095.

Line 1106: total_len -= ETHER_CRC_LEN (4), giving a signed-int range -4..4091.

Line 1108: the only guard is total_len < MINCLSIZE which routes small packets through m_devget (safe). For total_len >= MINCLSIZE the else branch (line 1116) is taken and line 1131 sets m->m_pkthdr.len = m->m_len = total_len on m = cur_rx->my_mbuf (line 1117) — an mbuf whose cluster was allocated in my_newbuf via MGETHDR+MCLGET (lines 1061, 1067) giving exactly MCLBYTES=2048 bytes of backing store, and whose DMA buffer size was advertised to the NIC as MCLBYTES-1=2047 at line 1076 (c->my_ptr->my_ctl = (MCLBYTES - 1) << MY_RBSShift).

No comparison of total_len against MCLBYTES (or against the RBS value) is ever performed.

m_devget (uipc_mbuf.c:2235) is NOT used in this branch — the original cluster is passed straight up.

For total_len in [2049, 4091] the stack reads 1..2043 bytes past the live cluster. Stale bytes are uninitialized heap (MCLGET does not zero), so the leak recovers prior packet contents or adjacent slab data.

Threat

Attacker position: a malicious or compromised PCIe NIC (VFIO/PCI passthrough, Thunderbolt, MTD80x silicon errata) that writes a descriptor status word with FLNG>2048 and MY_ES clear. The driver reads rxstat from DMA memory (line 1094) and trusts it unconditionally.

Under default driver config the MTD80x does NOT set MY_ALP (accept-long-packet) in MY_TCRRCR (my_init line 1428 programs only MY_TFTSF|MY_RBLEN|MY_RPBLE512), so a remote L2 attacker sending ordinary frames <=1518B cannot reach this path on correctly-functioning silicon — hence Medium, not High.

Impact once triggered: kernel heap info-leak (up to ~2043 bytes) via the network stack, or kernel panic when the OOB read hits an unmapped page (A:H availability).

Demonstrable locally with a kldload'd module that pokes a crafted rxstat, proving the missing-bound defect independent of hardware behavior. Same threat model as DF-1452 (if_ae, Medium).

Exploit / PoC

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

1. walks device_list / devclass my to find each my_softc,
2. waits for the interface to be IFF_UP and a packet to arrive,
3. locates the current RX descriptor via sc->my_cdata.my_rx_head->my_ptr,
4. atomically writes my_status = ((4095 << MY_FLNGShift) & MY_FLNGMASK) | MY_RXFSD | MY_RXLSD (FLNG=4095, no MY_ES, no MY_OWNByNIC) and lets my_rxeof run on the next interrupt.

my_rxeof computes total_len = 4095-4 = 4091, takes the else branch, sets m_len=4091 on a 2048-byte cluster, calls ifp->if_input. The ether_input / bpf_mtap / m_copydata traversal walks 2043 bytes past the cluster → panic (typical: vm_fault on unmapped page) or, with slab grooming so the trailing 2043 bytes are mapped, an info-leak of stale heap into an mbuf the stack then delivers to a raw socket the attacker reads.

Success looks like: Fatal trap 12: page fault while in kernel mode inside bcopy/ether_input chain, or leaked kernel pointers observable via an AF_RAW receive.

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

PoC angle B (no root, requires hostile PCIe): a qemu/KVM guest with a passed-through or crafted MTD80x function (or a malicious Thunderbolt NIC) writes a DMA descriptor with the crafted rxstat; the host running this driver hits the same path.

Recommended fix

Bound total_len to the RX buffer size before using it as m_len. The check also guards the underflow total_len<0 from FLNG<4:

--- a/sys/dev/netif/my/if_my.c
+++ b/sys/dev/netif/my/if_my.c
@@ -1103,6 +1103,17 @@ my_rxeof(struct my_softc * sc)
            continue;
        }
        /* No errors; receive the packet. */
        total_len = (rxstat & MY_FLNGMASK) >> MY_FLNGShift;
        total_len -= ETHER_CRC_LEN;

+       /*
+        * Validate the NIC-reported frame length against the RX
+        * buffer size.  The descriptor's RBS field was programmed
+        * to MCLBYTES-1 in my_newbuf; a malicious/buggy PCIe
+        * device can otherwise report FLNG up to 4095, making the
+        * stack walk past the 2KB mbuf cluster.
+        */
+       if (total_len < ETHER_HDR_LEN || total_len > MCLBYTES) {
+           IFNET_STAT_INC(ifp, ierrors, 1);
+           cur_rx->my_ptr->my_status = MY_OWNByNIC;
+           continue;
+       }
+
        if (total_len < MINCLSIZE) {
            m = m_devget(mtod(cur_rx->my_mbuf, void *),
                     total_len, 0, ifp);

This matches the pattern applied in sibling drivers (every other DFly NIC driver bounds rxd->len to MCLBYTES or the ring buffer size; see DF-1410, DF-1452, DF-1292, DF-1336).

Related findings

• DF-1410 (twin, if_xe): missing MCLBYTES check on RX length.
• DF-1452 (twin, if_ae): same RX-length OOB.
• DF-1131 (twin, bwn): same RX-length OOB.
• DF-1479 (sibling): my_start ignores my_encap failure in same file.