Summary

alloc_rx_buffers() attaches an mbuf cluster (MCLBYTES = 2048), sets m_len = 2048, then m_adj(m, 2) for IP alignment — leaving only 2046 bytes from m_data to the cluster boundary. The RX descriptor is then written with length = 0, which Conexant-style descriptor rings conventionally interpret as "use device max" (~11-bit max, 2047, matching the & 0x7ff mask in indicate_frames line 800). If the device DMAs more than 2046 bytes for an oversized received frame, it writes past the end of the cluster; if it writes exactly 2047 bytes, indicate_frames then sets m_len=2047 on a 2046-byte buffer, causing the network stack to read 1 byte past the cluster as well. The driver never tells the chip the actual buffer size.

Root cause

sys/dev/netif/sbsh/if_sbsh.c:775-784:

m->m_pkthdr.len = m->m_len = MCLBYTES;   /* 2048 */
...
m_adj(m, 2);                              /* m_data += 2, m_len -= 2 -> 2046 */
...
sc->rq[sc->tail_rq++] = m;
sc->tail_rq &= (RQLEN - 1);
sc->rbd[cur_rbd].address = vtophys(mtod(m, vm_offset_t));   /* phys(cluster+2) */
sc->rbd[cur_rbd].length  = 0;                                /* 'device max' */

And sys/dev/netif/sbsh/if_sbsh.c:799-800:

m->m_pkthdr.len = m->m_len = sc->rbd[sc->head_rdesc].length & 0x7ff;   /* up to 2047 */

MCLBYTES is 1<<11 = 2048 (sys/sys/param.h:495-497). After m_adj(m,2), m_data points 2 bytes into the cluster, leaving exactly 2046 bytes of physically-contiguous cluster before the next slab object. The descriptor length field is set to 0, not to 2046. The kernel-side readback masks with 0x7ff (max 2047). There is therefore a window of sizes (2047 and 2048) where the device writes past the cluster boundary (DMA overflow into adjacent slab object) and/or the kernel reports an m_len that exceeds the actual m_data buffer length (1-byte OOB read by upper network layers).

Threat model

Attacker is the peer at the far end of the G.SHDSL link (or any local user able to inject a frame into the path — e.g. via bridging). The peer sends a single Ethernet frame whose on-the-wire size, after the chip's own encapsulation, causes the CX28975 to DMA exactly 2047 or 2048 bytes into the descriptor. The 1-byte (or 2-byte) overflow lands in the next mbuf cluster in the mclzone slab, which on systems without a functioning IOMMU is directly writable by the device. Corruption of an adjacent mbuf cluster can in turn corrupt another socket's RX data or slab metadata.

Realistic worst case is corruption of a small region of network data (DoS / subtle protocol-level integrity break); escalation to code execution would require heap grooming to land the overflow on a victim function pointer, which is feasible but not demonstrated here.

Confidence speculative because the exact meaning of length=0 to this specific Conexant firmware is undocumented in-tree and depends on chip behavior for oversized frames — the bug is concrete (driver writes 0 where it should write the buffer capacity), but its exploitability depends on whether the chip ever actually DMAs more than 2046 bytes.

PoC

Requires a peer (or attacker in the G.SHDSL forwarding path). Send an Ethernet frame sized to land at 2047 bytes after chip encapsulation. Concrete framing depends on the CX28975 firmware but a useful probe is to walk up sizes near SBNI16_MAX_FRAME (1552) and 2046/2047/2048 while watching KTR/mbufwatch for cross-cluster corruption or "m_len claims X but cluster has Y" KASSERTs in upper layers.

A reproducible demonstration requires either a live sbsh peer or a USB→G.SHDSL emulator and is left to the PoC runner; the in-tree proof that the bug exists is the size mismatch itself: buffer 2046 bytes, descriptor length 0, readback mask 0x7ff.

Recommended fix

Tell the device the actual buffer capacity. Set the descriptor length to the post-alignment usable size, and reject received frames that report a length larger than the buffer:

--- a/sys/dev/netif/sbsh/if_sbsh.c
+++ b/sys/dev/netif/sbsh/if_sbsh.c
@@ -782,8 +782,9 @@ alloc_rx_buffers(struct sbsh_softc *sc)
        sc->rq[sc->tail_rq++] = m;
        sc->tail_rq &= (RQLEN - 1);

-       sc->rbd[cur_rbd].address = vtophys(mtod(m, vm_offset_t));
-       sc->rbd[cur_rbd].length  = 0;
+       /* m_adj(m,2) above leaves MCLBYTES-2 bytes; cap the device to that. */
+       sc->rbd[cur_rbd].address = vtophys(mtod(m, vm_offset_t));
+       sc->rbd[cur_rbd].length  = m->m_len;
        sc->regs->LRDR = cur_rbd = (cur_rbd + 1) & 0x7f;
    }
 }
@@ -795,8 +796,14 @@ indicate_frames(struct sbsh_softc *sc)
    unsigned  cur_rbd = sc->regs->CRDR & 0x7f;

    while (sc->head_rdesc != cur_rbd) {
+       u_int32_t rxlen;
        struct mbuf  *m = sc->rq[sc->head_rq++];
        sc->head_rq &= (RQLEN - 1);

-       m->m_pkthdr.len = m->m_len =
-               sc->rbd[sc->head_rdesc].length & 0x7ff;
+       rxlen = sc->rbd[sc->head_rdesc].length & 0x7ff;
+       if (rxlen > MCLBYTES - 2) { /* defensive: device lied about size */
+           IFNET_STAT_INC(ifp, ierrors, 1);
+           m_freem(m);
+           goto skip;
+       }
+       m->m_pkthdr.len = m->m_len = rxlen;
        m->m_pkthdr.rcvif = ifp;

        ifp->if_input(ifp, m, NULL, -1);
@@ -806,6 +813,7 @@ indicate_frames(struct sbsh_softc *sc)

        sc->head_rdesc = (sc->head_rdesc + 1) & 0x7f;
+   skip: ;
    }
 }

Alternatively, drop the m_adj(m,2) alignment pre-amble and instead reserve headroom with m_data = cluster + 2 at allocation, leaving the descriptor length at MCLBYTES so the chip cannot overrun.

Related findings

NIC RX length OOB family — same class as: - 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), DF-1562 (if_pcn), DF-1614 (if_sln)