• File: sys/dev/netif/sf/if_sf.c
• Lines: 883, 886, 890, 893, 945, 951, 952, 1164, 1169
• Severity: Medium
• CVSS: CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:H
• CWE: CWE-787 Out-of-bounds Write
• Confidence: likely

Summary

sf_rxeof() feeds the hardware-reported 16-bit frame length cur_rx->sf_len directly into m_devget() as cur_rx->sf_len + ETHER_ALIGN with no upper-bound check, but the source RX mbuf cluster only has MCLBYTES - sizeof(u_int64_t) = 2040 bytes of usable DMA space because sf_newbuf() pre-advances m_data by 8 bytes via m_adj(m_new, sizeof(u_int64_t)).

Compounding this, sf_init() programs the chip's RX buffer-length register (SF_RXDQ_CTL_1[31:16]) to MCLBYTES (2048) instead of MCLBYTES-8 (2040), so the NIC believes it has 2048 bytes of DMA target space when only 2040 actually exist.

If the chip ever produces a descriptor with sf_len > 2040, m_devget() reads past the end of the cluster (kernel heap info leak into the delivered packet), and the chip's own DMA has already written up to 8 bytes past the end of the cluster (attacker-controlled heap overflow).

The sibling driver if_wb.c has an explicit guard for this exact pattern at sys/dev/netif/wb/if_wb.c:984 (> 1536) that resets the chip on overflow; if_sf.c has none.

Root cause

Two coupled defects, both stemming from failure to account for the sizeof(u_int64_t)=8 alignment headroom reserved in the RX cluster.

(a) In sf_newbuf() at if_sf.c:867-897: a cluster is allocated (MCLGET at :878), m_len/pkthdr.len set to MCLBYTES=2048 at :883/:886, then m_adj(m_new, sizeof(u_int64_t)) at :890 advances m_data by 8 bytes, leaving only 2040 bytes (ext_buf+8 .. ext_buf+2047) reachable from m_data.

The DMA address programmed at :893 (c->sf_addrlo = SF_RX_HOSTADDR(vtophys(mtod(m_new, caddr_t)))) is ext_buf+8, so the chip DMAs starting at ext_buf+8.

(b) In sf_init() at if_sf.c:1169: csr_write_4(sc, SF_RXDQ_CTL_1, (MCLBYTES << 16) | SF_DESCSPACE_16BYTES) tells the chip the per-buffer length is MCLBYTES=2048, but the real post-m_adj space is only 2040 bytes — an 8-byte overstatement.

(c) In sf_rxeof() at if_sf.c:936-964: the loop dequeues completion descriptors and unconditionally calls m_devget(mtod(m, char *) - ETHER_ALIGN, cur_rx->sf_len + ETHER_ALIGN, 0, ifp) at :951–952.

cur_rx->sf_len is a u_int32_t:16 bitfield (if_sfreg.h:729, max 65535) written by the NIC. There is no comparison against MCLBYTES - sizeof(u_int64_t) (or any cap) anywhere in the function.

m_devget() (sys/kern/uipc_mbuf.c:2235) allocates a destination mbuf chain sized to fit len but bcopy()s len bytes from the source at line 2261 — so an inflated len is a straight OOB read of the source cluster.

Math:

• source base = ext_buf+6 (m_data - ETHER_ALIGN),
• readable source span = ext_buf+6 .. ext_buf+2047 = 2042 bytes;
• read length = sf_len+2;
• OOB iff sf_len > 2040.

The DMA-write side overflows iff sf_len > 2040 (chip writes ext_buf+8+sf_len-1 > ext_buf+2047), bounded by the chip's 2048-byte belief to an 8-byte write.

Note SF_RXDMA_REPORTBADPKTS is set at if_sf.c:1164, so even malformed/error frames are surfaced to this path.

Threat

Attacker is an unauthenticated on-link (or reachable via L2) network peer who can transmit Ethernet frames to a host with an sf(4) interface that is IFF_UP.

The path is purely RX: packet → NIC DMA → sf_intr → sf_rxeof → m_devget → ifp->if_input → network stack / BPF / userland sockets.

Trigger precondition: the chip must accept (or pass through under SF_RXDMA_REPORTBADPKTS) a frame whose reported length exceeds 2040 bytes.

With the driver as written, SF_MACCFG1_HUGEFRAMES (if_sfreg.h:590) is NOT set and SF_MAXLEN (if_sfreg.h:578) is never programmed, so the chip's reset-default MAXLEN (~1518/1536 per the AIC-6915 datasheet) normally clamps frames below the 2040 threshold and the bug is latent in default config.

Impact when triggered:

1. Info leak — m_devget reads up to (65535 - 2040) = ~62 KB of kernel heap past the cluster, copying it into an mbuf delivered to the network stack and visible via raw sockets / AF_INET sockets / tcpdump/BPF; leaked bytes may include credentials, socket buffers, or other clusters' contents.
2. Kernel heap corruption — the NIC's DMA writes 1..8 bytes of attacker-controlled packet payload past the cluster into whatever slab object is adjacent (mbufs, file descriptors, arpcom, etc.), enabling groomed heap-corruption primitives up to kernel privilege escalation.
3. Local unprivileged user without send access to sf0 can also read leaked bytes via a receiving socket if the host is in promiscuous mode (sf_ioctl SIOCSIFFLAGS sets SF_RXFILT_PROMISC at if_sf.c:516).

Exploit / PoC

Reproduce the defect (proof of bug, escalating to proof of impact with a config precondition):

1. Build a witness: a DragonFlyBSD host with an Adaptec AIC-6915 NIC exposed as sf0 (or, for the leak-demonstration variant, any NIC whose driver is patched to call sf_rxeof).
2. From a peer on the same L2 segment, send oversized Ethernet frames. Save as findings/poc/DF-1526/send_oversized.py:

python from scapy.all import * iface = 'eth0' dst = getmacbyip('10.0.0.1') payload = b'A' * 9000 sendp(Ether(dst=dst)/LLC()/payload, iface=iface, count=50)

3. On the victim, run tcpdump -i sf0 -w out.pcap -s 0 -X in parallel.
4. In default config the chip drops the frame at MAXLEN, demonstrating the latent state; to demonstrate the active bug, raise the threshold: either (a) load a kld that ORs SF_MACCFG1_HUGEFRAMES into SF_MACCFG_1 via csr_write_4 — the driver already exposes no knob, so a 3-line kernel module calling csr_write_4(sc, SF_MACCFG_1, csr_read_4(sc, SF_MACCFG_1) | SF_MACCFG1_HUGEFRAMES) suffices, or (b) more realistically, observe that the buffer-length register is already mis-set to 2048, so once HUGEFRAMES is enabled the 8-byte DMA overflow is immediate.
5. Success criteria: the leaked kernel heap bytes appear in out.pcap beyond byte offset 2040 of a received "frame", OR (for the write side) the host panics with a slab/page-fault corruption signature in dmesg.txt shortly after sending.

Capture: env.txt (uname -a, ifconfig sf0, sysctl dev.sf.0), run.log (full dmesg including panic), leak_sample.txt (hexdump of bytes past 2040 from out.pcap).

For a root-escalation chain, the 8-byte DMA overflow lands in the next slab object; groom the RX-cluster slab (trigger many MCLGET/MCLFREE cycles from another socket) so the adjacent object is a controlled-victims struct (e.g., another mbuf cluster's m_ext control block), then overwrite a function pointer field to redirect to a user-controlled shellcode buffer — the standard NIC-heap-overflow escalation template.

Recommended fix

Add an explicit upper-bound on cur_rx->sf_len before m_devget, and program the chip's RX buffer length to the actual usable size (MCLBYTES - sizeof(u_int64_t)) so the NIC's DMA cannot exceed the cluster.

--- a/sys/dev/netif/sf/if_sf.c
+++ b/sys/dev/netif/sf/if_sf.c
@@ -942,6 +942,17 @@ sf_rxeof(struct sf_softc *sc)
        SF_INC(cmpconsidx, SF_RX_CLIST_CNT);
        SF_INC(bufprodidx, SF_RX_DLIST_CNT);

+       /*
+        * Defensive bounds check: sf_len is a 16-bit hardware-reported
+        * length with no upstream clamp. The RX cluster has only
+        * MCLBYTES - sizeof(u_int64_t) bytes of DMA space after the
+        * m_adj() headroom in sf_newbuf(); a length beyond that would
+        * both overflow the cluster via DMA and cause m_devget() to
+        * read past the end of the cluster into adjacent kernel heap.
+        */
+       if (cur_rx->sf_len > MCLBYTES - sizeof(u_int64_t)) {
+           IFNET_STAT_INC(ifp, ierrors, 1);
+           sf_newbuf(sc, desc, m);
+           continue;
+       }
+
        if (!(cur_rx->sf_status1 & SF_RXSTAT1_OK)) {
            IFNET_STAT_INC(ifp, ierrors, 1);
            sf_newbuf(sc, desc, m);
@@ -1166,7 +1177,8 @@ sf_init(void *xsc)
    /* Init the RX buffer descriptor queue. */
    csr_write_4(sc, SF_RXDQ_ADDR_Q1,
        vtophys(sc->sf_ldata->sf_rx_dlist_big));
-   csr_write_4(sc, SF_RXDQ_CTL_1, (MCLBYTES << 16) | SF_DESCSPACE_16BYTES);
+   csr_write_4(sc, SF_RXDQ_CTL_1,
+       ((MCLBYTES - sizeof(u_int64_t)) << 16) | SF_DESCSPACE_16BYTES);
    csr_write_4(sc, SF_RXDQ_PTR_Q1, SF_RX_DLIST_CNT - 1);

The first hunk is the load-bearing fix (kills the m_devget OOB read); the second hunk removes the 8-byte DMA-write overflow at the source by telling the chip the truth about its DMA target size.

Together they make sf_rxeof safe for any value the NIC can place in sf_len, including the SF_RXDMA_REPORTBADPKTS path.

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-1452 (twin, if_ae): same RX-length OOB.
• DF-1131 (twin, bwn): same RX-length OOB.
• DF-1517 (twin, ath): wifi RX length OOB.